diff --git a/en_US.ISO8859-1/articles/cvs-freebsd/article.sgml b/en_US.ISO8859-1/articles/cvs-freebsd/article.sgml index 11443bf34d..abc02890fc 100644 --- a/en_US.ISO8859-1/articles/cvs-freebsd/article.sgml +++ b/en_US.ISO8859-1/articles/cvs-freebsd/article.sgml @@ -1,683 +1,690 @@ %man; %authors; + +%trademarks; ]>
Setting up a CVS repository - the FreeBSD way Stijn Hoop
stijn@win.tue.nl
 2001 2002 2003 Stijn Hoop $FreeBSD$ + + &tm-attrib.freebsd; + &tm-attrib.general; + + This article describes the steps I took to setup a CVS repository that uses the same scripts the FreeBSD project uses in their setup. This has several advantages over a stock CVS setup, including more granular access control to the source tree and generation of readable email of every commit. Introduction Most of the open source software projects use CVS as their source code control system. While CVS is pretty good at this, it has its share of flaws and weaknesses. One of these is that sharing a source tree with other developers can quickly lead to a system administration nightmare, especially if one wishes to protect parts of the tree from general access. FreeBSD is one of the projects using CVS. It also has a large base of developers located around the world. They developed some scripts to make management of the repository easier. Recently, these scripts were revisited and normalized by &a.joe; to make it easier to reuse them in other projects. This article describes one method of using the new scripts. To make the most use of the information in this article, you need to be familiar with the basic method of operation of CVS. First setup It might be best to first perform this procedure with an empty test repository, to make sure you understand all consequences. As always, make sure you have recent, readable backups! Initializing the repository The first thing to do when setting up a new repository is to tell CVS to initialize it: &prompt.user; cvs -d path-to-repository init This tells CVS to create the CVSROOT administrative directory, where all the customization takes place. The repository group Now we will create the group which will own the repository. All committers need to be in this group, so that they can write to the repository. We will assume the FreeBSD default of ncvs for this group. &prompt.root; pw groupadd ncvs Next, you should &man.chown.8; the directory to the group you just added: &prompt.root; chown -R :ncvs path-to-your-repository This ensures that no one can write to the repository without proper group permissions. Getting the sources Now you need to obtain the CVSROOT directory from the FreeBSD repository. This is most easily done by checking it out from a FreeBSD anonymous CVS mirror. See the relevant chapter in the handbook for more information. Let us assume that the sources are stored in CVSROOT-freebsd in the current directory. Copying the FreeBSD scripts Next, we will copy the FreeBSD CVSROOT sources into your own repository. If you are accustomed to CVS, you might be thinking that you can just import the scripts, in an attempt to make synchronizing with later versions easier. However, it turns out that CVS has a deficiency in this area: when importing sources into the CVSROOT directory, it will not update the needed administrative files. In order to make it recognize those, you will need to checkin each file after importing them, losing the value of cvs import. Therefore, the recommended method is to simply copy over the scripts. It does not matter if the above paragraph did not make sense to you—the end result is the same. Simply check out your CVSROOT and copy the FreeBSD files over your local (untouched) copies: &prompt.user; cvs -d path-to-your-repository checkout CVSROOT &prompt.user; cd CVSROOT &prompt.user; cp ../CVSROOT-freebsd/* . &prompt.user; cvs add * Note that you will probably get a few warnings about some directories not being copied; this is normal, you do not need those. The scripts Now you have in your working directory an exact copy of the scripts that the FreeBSD project itself uses for their repository. A summary of what each file is used for is included below. access - this file is not used in the default setup. It is used in the FreeBSD project specific setup, where it controls access to the repository. You can remove this file if you do not wish to use this setup. avail - this file controls access to the repository. In this, you can specify groups of people that are allowed access to the repository, as well as disallow commits on a per-directory basis. You should tailor it to contain the groups and directories that will be in your repository. cfg.pm - this file parses your configuration, and provides the default configuration. You should not make changes to this file. Instead, put your configuration changes in cfg_local.pm. cfg_local.pm - this file contains all configurable parameters of the system. You should configure all sorts of settings here, such as where commit mail is send, on what hosts people can commit, and others. More information on this below. checkoutlist - this files lists all files under control of CVS in this directory, apart from the standard ones created by cvs init. You should edit this to remove some FreeBSD-specific files. commit_prep.pl - this script performs various pre-commit checks, based on whether you enabled them in your cfg_local.pm. You should not have to touch this. commitcheck - this script is invoked directly from CVS. It first checks if the committer has access to the specified part of the tree using cvs_acls.pl, and then runs commit_prep.pl for the various pre-commit checks. If those are OK, CVS will allow the commit to proceed. You should not have to touch this file. commitinfo - this file is used by CVS to determine which script to run before a commit—in this case commitcheck. You should not have to touch this file. config - the configuration file for this repository. You should change this as needed, but most administrators can probably leave the defaults. More information on the options that can be set here can be found in the CVS manual. cvs_acls.pl - this script determines the committers identity, and whether he/she is allowed access to the tree. It does this based on the avail file. You should not have to touch this file. cvsignore - this file specifies files that CVS should not checkin in the repository. You can edit this as you wish. More information about this file is available in the CVS manual. cvswrappers - this file is used by CVS to enable or disable keyword expansion, or whether a file should be considered binary. You can edit this as you wish. More information about this file is available in the CVS manual. Note that the -t and -f options do not work correctly with client/server CVS. edithook - this file is not used any more, but kept for historic reasons. You can safely remove this file. editinfo - CVS uses this file for editor overrides. FreeBSD does not use this functionality, as parsing the log message is done by verifymsg and logcheck. This is because the editinfo functionality does not work properly with remote commits, or ones that use the -m or -F options. You should not have to touch this file. exclude - this file lists regular expressions that are used by commit_prep.pl to determine files which cannot contain a revision header. In the FreeBSD setup, all files under revision control need to have a revision header (like $FreeBSD$). All filenames that match one of the lines in this file are exempted from this check. You should add expressions to this file as you checkin files that cannot have a revision header. For the purpose of installing the scripts, it may be best to exclude CVSROOT/ from header checks. log_accum.pl - this is a script that takes the log message as provided by the logcheck script, and appends it to a log file in the repository for backup purposes. It also handles mailing out a message to an email address you provide (in cfg_local.pm). It hooks into CVS via loginfo. You should not have to touch this file. logcheck - this file parses the commit log message that committers provide, and attempts to sanitize it somewhat. It hooks into CVS via verifymsg. You should not have to touch this file. This script depends on a local FreeBSD hack of CVS: this version reads the log message back in after this script has modified it. The stock version of CVS does not do this which makes logcheck unable to clean up the log message, although it is still able to check that it is syntactically OK. CVS 1.11.2 can be configured to have the same behaviour as FreeBSD's version by setting RereadLogAfterVerify=always in the config file. loginfo - this file is used by CVS to control where log information is sent; log_accum.pl hooks in here. You should not have to touch this file. modules - this file retains its traditional meaning in CVS. You should remove the FreeBSD modules from the stock version. You can edit this as you wish. More information about this file is available in the CVS manual. notify - this file is used by CVS in case someone sets a watch on a file. It is not used in the FreeBSD repository. You can edit this as you wish. More information about this file is available in the CVS manual. options - this file is specific to the FreeBSD version of CVS, and is also supported by the Debian version. It contains the keyword to expand in revision headers. You should alter this to match the keyword you specified in cfg_local.pm (if you use that feature, which is FreeBSD specific for now). rcsinfo - this file maps directories in the repository to template files such as rcstemplate. By default, FreeBSD uses one template for the whole repository. You can add others to this file if you wish. rcstemplate - this file is the actual template committers will see when they make a checkin. You should edit this to describe the various extra parameters you defined in cfg_local.pm. tagcheck - this files controls access to tagging in the repository. The stock FreeBSD version disallows tags with names of RELENG*, because of the release engineering process. You should edit this file as desired. taginfo - this file maps tag operations on repository directories to access control scripts such as tagcheck. You should not have to touch this file. unwrap - this script can be used to automatically unwrap binary files (see cvswrappers) on checkout. It is not used in the current FreeBSD setup because the functionality it hooks into does not work well with remote commits. You should not have to touch this file. verifymsg - this file maps repository directories to post processor scripts of log messages such as logcheck. You should not have to touch this file. wrap - this script can be used to automatically wrap binary files (see cvswrappers) on checkin. It is not used in the current FreeBSD setup because the functionality it hooks into does not work well with remote commits. You should not have to touch this file. Customizing the scripts The next step is to setup the scripts so that they work in your environment. You should go over all files in the directory and make your customizations. In particular, you might want to do edit the following files: If you do not wish to use the FreeBSD specific features of the scripts, you can safely remove the access file: &prompt.user; cvs rm -f access Edit avail to contain the various repository directories in which you want to control access. Make sure you retain the avail||CVSROOT line, otherwise you will lock yourself out in the next step. The other thing you can add in this file are committer groups. By default, FreeBSD uses the access file to list all its committers in, but you can use any file you wish. You can also add groups if you want (the syntax is specified at the top of cvs_acls.pl). Edit cfg_local.pm to contain the options you want. In particular, you should take a look at the following configurable items: %TEMPLATE_HEADERS - these get processed by the log scripts, and inserted below the commit mail if present and non-empty in the commit message. You can probably remove the PR and MFC after entries. And of course you can add your own. $MAIL_BRANCH_HDR - if you want to insert a header into each commit mail describing the branch on which the commit was made, define this to match your setup. Or leave it empty if you do not want such a header. @COMMIT_HOSTS - define this to be a list of hosts on which people can commit. $MAILADDRS - set this to the admin or list address that should receive commit mail. @LOG_FILE_MAP - change this array as you wish - each regexp is matched on the directory of the commit, and the commit log message gets stored in the commitlogs subdirectory in the filename mentioned. $COMMITCHECK_EXTRA - if you do not want to use the FreeBSD specific access checks, you should remove the definition of $COMMITCHECK_EXTRA from this file. Changing the $IDHEADER parameter is only guaranteed to work on FreeBSD platforms; it depends on FreeBSD specific modifications to CVS. You can check cfg.pm to see which other options can be changed, but the above is a reasonable subset. Edit exclude to remove the FreeBSD specific entries (such as all lines beginning with ^ports/ etc.). Furthermore, comment out the lines beginning with ^CVSROOT/, and add one line with only ^CVSROOT/ on it. After the wrapper is installed, you can add your header to the files in the CVSROOT directory and restore these lines, but for now they will only be in the way when you try to commit later on. Edit modules, and delete all FreeBSD stuff. Add your own modules if you wish. This step is only necessary if you specified a value for $IDHEADER in cfg_local.pm (which only works using a FreeBSD modified CVS). Edit options to match the tag you specified in cfg_local.pm. A global search and replace of FreeBSD with your tag should suffice. Edit rcstemplate to contain the same keywords as specified in cfg_local.pm. Optionally remove the FreeBSD checks from tagcheck. You can simply add exit 0 to the top of the file to disable all checks on tagging. The last thing to do before you are finished, is to make sure the commitlogs can be stored. By default these are stored in the repository, in the commitlogs subdirectory of the CVSROOT directory. This directory needs to be created, so do the following: &prompt.user; mkdir commitlogs &prompt.user; cvs add commitlogs Now, after careful review, you should commit your changes. Be sure that you have granted yourself access to the CVSROOT directory in your avail before you do this, because otherwise you will lock yourself out. So make sure everything is as you intend, and then do the following: &prompt.user; cvs commit -m '- Initial FreeBSD scripts commit' Testing the setup You are ready for the first test: a forced commit to the avail file, to make sure everything works as expected. &prompt.user; cvs commit -f -m 'Forced commit to test the new CVSROOT scripts' avail If everything works, congratulations! You now have a working setup of the FreeBSD scripts for your repository. If CVS still complains about something, go back and recheck if all of the above steps have been performed correctly. FreeBSD specific setup The FreeBSD project itself uses a slightly different setup, which also uses files from the freebsd subdirectory of the FreeBSD CVSROOT. The project uses this because of the large number of committers, which all would have to be in the same group. So, a simple wrapper was written which ensures that people have the correct credentials to commit, and then sets the group id to that of the repository. If your repository also needs this, the steps to set this up are documented below. But first an overview of the files involved. Files used in the FreeBSD setup access - this file controls access information. You should edit this file to include all members of your project. freebsd/commitmail.pl - this file is not used any more, but kept for historic reasons. You should not have to touch this file. freebsd/cvswrap.c - this is the source to the CVS wrapper that you will need to install to make all access checks actually work. More information on this below. You should edit the paths in the ACCESS and REALCVS macros to match your setup. freebsd/mailsend.c - this file is needed by the FreeBSD setup of the mailing lists. You should not have to touch this file. The procedure Edit the access file to contain only your username. Edit cvswrap.c to contain the correct path for your setup. This is defined in a macro named ACCESS. You should also change the location of the real cvs binary if it is not appropriate to your situation. The stock cvswrap.c expects to be a replacement for the systemwide cvs command, which will be moved to /usr/bin/ncvs. My copy of cvswrap.c has this: #define ACCESS "/local/cvsroot/CVSROOT/access" #define REALCVS "/usr/bin/ncvs" Next up is installing the wrapper to ensure you become the correct group when committing. The sources for this live in cvswrap.c in your CVSROOT. Compile the sources that you edited to include the correct paths: &prompt.user; cc -o cvs cvswrap.c And then install them (you have to be root for this step): &prompt.root; mv /usr/bin/cvs /usr/bin/ncvs &prompt.root; mv cvs /usr/bin/cvs &prompt.root; chown root:ncvs /usr/bin/cvs /usr/bin/ncvs &prompt.root; chmod o-rx /usr/bin/ncvs &prompt.root; chmod u-w,g+s /usr/bin/cvs This installs the wrapper as the default cvs command, making sure that anyone who wants to use the repository has to have the correct access levels. You can now remove everyone from your repository group. All access control is done by your wrapper, and this wrapper will set the correct group for access. Testing the setup Your wrapper should now be setup. You can of course test this by making a forced commit to the access file: &prompt.user; cvs commit -f -m 'Forced commit to test the new CVSROOT scripts' access Again, if this fails, check to see whether all of the above steps have been executed correctly.
diff --git a/en_US.ISO8859-1/articles/cvsup-advanced/article.sgml b/en_US.ISO8859-1/articles/cvsup-advanced/article.sgml index 9c21e49762..9575640d77 100644 --- a/en_US.ISO8859-1/articles/cvsup-advanced/article.sgml +++ b/en_US.ISO8859-1/articles/cvsup-advanced/article.sgml @@ -1,264 +1,272 @@ %man; + + +%trademarks; ]>
CVSup Advanced Points Salvo Bartolotta
bartequi@neomedia.it
 $FreeBSD$ + + &tm-attrib.freebsd; + &tm-attrib.general; + + The present article assumes a basic understanding of CVSup operation. It documents several delicate issues connected with source synchronization via CVSup, viz. effective solutions to the problem of stale files as well as special source updating cases; which issues are likely to cause apparently inexplicable troubles. Preface This document is the fruit of the author's attempts to fully understand the niceties of CVSup & source updating. :-) While the author has made every effort to make these pages as informative and correct as possible, he is only human and may have made all sorts of typos, mistakes, etc. He will be very grateful for any comments and/or suggestions you send to his e-mail address, bartequi@neomedia.it. Introduction If you have visited John Polstra's site and read his FAQ, you may have noticed Question 12 & 13. When updating any collection of sources (eg /usr/ports), &man.cvsup.1; makes use of the related checkouts file in order to perform the updating process in the most efficient and correct way. In this example (/usr/ports), the related checkouts file is /usr/sup/ports-all/checkouts.cvs:. if your base is /usr. A checkouts file contains information on the current status of your sources—in a way, a sort of photograph. This significant information enables cvsup to retrieve updates most effectively. Further, and maybe more important, it enables cvsup to correctly manage your sources by locally deleting any files no longer present in the repository, thus leaving no stale files on your system. In fact, without a checkouts file, cvsup would not know which files your collection was composed of (cf &man.cvsup.1; and the fallback method for details); as a result, it could not delete on your system those files no longer present in the repository. They would remain on your system (stale files), and might cause you subtle build failures or other trouble. For example, this problem is likely to occur if you first update your ports collection several weeks after you got your installation CD-ROMs. It is therefore recommended that you adopt the two-step procedure outlined in the CVSup FAQ (cf Q12, Q13); in subsequent sections, you will be given interesting and instructive concrete examples. A useful python script: <command>cvsupchk</command> Alternatively, in order to examine your sources for inconsistencies, you may wish to utilize the cvsupchk python script; which script is currently found in /usr/ports/net/cvsup/work/cvsup-16.1/contrib/cvsupchk, together with a nice README. Prerequisites: /usr/ports/net/cvsup &prompt.root; make extract python (also found in the ports collection :-)) a checkouts file for your collection of sources. If you are updating your sources for the very first time, of course you do not have a checkouts file. After installing python and updating your sources (eg /usr/ports), you can check them thus: &prompt.user; /path/to/cvsupchk -d /usr -c /usr/sup/ports-all/checkouts.cvs:. | more If you want to check your RELENG_4 sources: &prompt.user; /path/to/cvsupchk -d /usr -c /usr/sup/src-all/checkouts.cvs:RELENG_4 | more In each case, cvsupchk will inspect your sources for inconsistencies by utilizing the information contained in the related checkouts file. Such anomalies as deleted files being present (aka stale files), missing checked-out files, extra RCS files, and dead directories will be printed to standard output. In the next section, we will provide important, typical examples of source updating; which examples will show you the role of checkouts files and the dangers of negligent source management. Examples of more advanced source management How to safely change tags when updating <literal>src-all</literal> If you specify eg tag=A in your supfile, cvsup will create a checkouts file called checkouts.cvs:A: for instance, if tag=RELENG_4, a checkouts file called checkouts.cvs:RELENG_4 is generated. This file will be used to retrieve and/or store information identifying your 4-STABLE sources. When tracking src-all, if you wish to pass from tag=A to tag=B (A less/greater than B not making any difference) and if your checkouts file is checkouts.cvs:A, the following actions should be performed: &prompt.root; mv checkouts.cvs:A checkouts.cvs:B (This provides the subsequent step with the appropriate checkouts file) write a supfile whose collection line reads: src-all tag=B cvsup your sources using the new supfile. The cvsup utility will look for checkouts.cvs:B—in that the target is B; that is, cvsup will make use of the information contained therein to correctly manage your sources. The benefits: the sources are dealt with correctly (in particular, no stale files) less load is placed on the server, in that cvsup operates in the most efficient way. For example, A=RELENG_4, B=.. The period in B=. means -CURRENT. This is a rather typical update, from 4-STABLE to -CURRENT. While it is straightforward to downgrade your sources (eg from -CURRENT to -STABLE), downgrading a system is quite another matter. You are STRONGLY advised not to attempt such an operation, unless you know exactly what you are doing. Updating to the same tag as of a different date If you wish to switch from tag=A to tag=A as of a different GMT date (say, date=D), you will execute the following: write a supfile whose collection line reads: src-all tag=A date=D update your sources using the new supfile Whether the new date precedes that of the last sync operation with tag=A or not, it is immaterial. For example, in order to specify the date August 27, 2000, 10:00:00 GMT you write the line: src-all tag=RELENG_4 date=2000.08.27.10.00.00 The format of a date is rigid. You have to specify all the components of the date: century (20, ie the 21st century, must be supplied whereas 19, the past century, can be omitted), year, month, day, hour, minutes, seconds—as shown in the above example. For more information, please see &man.cvsup.1;. Whether or not a date is specified, the checkouts file is called checkouts.cvs:A (eg checkouts.cvs:RELENG_4). As a result, no particular action is needed in order to revert to the previous state: you have to modify the date in the supfile, and run csvup again. Updating your ports collection for the first time Since ports are tagged . (ie -CURRENT), you can correctly sync them for the first time by adding the date keyword (cf &man.cvsup.1; for the exact format): you should specify a date as close as possible to that of shipping of your ports tree. After cvsup has correctly created the ports checkouts file, which is precisely the goal of this first special sync operation, the date field must be removed; all subsequent updates will be carried out smoothly. If you have been reading the apparently nit-picking remarks in these sections, you will probably have recognized the potential for trouble in a source updating process. A number of people have actually run into problems. You have been warned. :-)
diff --git a/en_US.ISO8859-1/articles/dialup-firewall/article.sgml b/en_US.ISO8859-1/articles/dialup-firewall/article.sgml index 8ae2026104..1bc1775ce6 100644 --- a/en_US.ISO8859-1/articles/dialup-firewall/article.sgml +++ b/en_US.ISO8859-1/articles/dialup-firewall/article.sgml @@ -1,381 +1,389 @@ %man; + + +%trademarks; ]>
Dialup firewalling with FreeBSD Marc Silver
marcs@draenor.org
 $FreeBSD$ + + &tm-attrib.freebsd; + &tm-attrib.general; + + This article documents how to setup a firewall using a PPP dialup with FreeBSD and IPFW, and specifically with firewalling over a dialup with a dynamically assigned IP address. This document does not cover setting up your PPP connection in the first place. Preface Dialup Firewalling with FreeBSD This document covers the process that is required to setup firewalling with FreeBSD when an IP address is assigned dynamically by your ISP. While every effort has been made to make this document as informative and correct as possible, you are welcome to mail your comments/suggestions to the marcs@draenor.org. Kernel Options The first thing you will need to do is recompile your kernel. If you need more information on how to recompile the kernel, then the best place to start is the kernel configuration section in the Handbook. You need to add the following options into your kernel configuration file: options IPFIREWALL Enables the kernel's firewall code. options IPFW2 Enables the new version of IPFW. Only do this if you're running FreeBSD 4.X, this is the default in newer versions of FreeBSD. options IPFIREWALL_VERBOSE Sends logged packets to the system logger. options IPFIREWALL_VERBOSE_LIMIT=100 Limits the number of times a matching entry is logged. This prevents your log file from filling up with lots of repetitive entries. 100 is a reasonable number to use, but you can adjust it based on your requirements. options IPDIVERT Enables divert sockets, which will be shown later. There are some other optional items that you can compile into the kernel for some added security. These are not required in order to get firewalling to work, but some more paranoid users may want to use them. options TCP_DROP_SYNFIN This option ignores TCP packets with SYN and FIN. This prevents tools like security/nmap from identifying the TCP/IP stack of the machine, but breaks support for RFC1644 extensions. This is not recommended if the machine will be running a web server. Do not reboot once you have recompiled the kernel. Hopefully, we will only need to reboot once to complete the installation of the firewall. Changing <filename>/etc/rc.conf</filename> to load the firewall We now need to make some changes to /etc/rc.conf in order to tell it about the firewall. Simply add the following lines: firewall_enable="YES" firewall_script="/etc/firewall/fwrules" natd_enable="YES" natd_interface="tun0" natd_flags="-dynamic" For more information on the functions of these statements take a look at /etc/defaults/rc.conf and read &man.rc.conf.5; Disable PPP's network address translation You may already be using PPP's built in network address translation (NAT). If that is the case then you will have to disable it, as these examples use &man.natd.8; to do the same. If you already have a block of entries to automatically start PPP, it probably looks like this: ppp_enable="YES" ppp_mode="auto" ppp_nat="YES" ppp_profile="profile" If so, you will need to specifically disable ppp_nat by making sure you have ppp_nat="NO" in /etc/rc.conf. You will also need to remove any nat enable yes or alias enable yes in /etc/ppp/ppp.conf. The rule set for the firewall We are nearly done now. All that remains now is to define the firewall rules and then we can reboot and the firewall should be up and running. I realize that everyone will want something slightly different when it comes to their rule base. What I have tried to do is write a rule base that suits most dialup users. You can obviously modify it to your needs by using the following rules as the foundation for your own rule base. First, let's start with the basics of closed firewalling. What you want to do is deny everything by default and then only open up for the things you really need. Rules should be in the order of allow first and then deny. The premise is that you add the rules for your allows, and then everything else is denied. :) Now, let's make the dir /etc/firewall. Change into the directory and edit the file fwrules as we specified in rc.conf. Please note that you can change this filename to anything you wish. This guide just gives an example of a filename. Now, let's look at a sample firewall file, that is commented nicely. # Define the firewall command (as in /etc/rc.firewall) for easy # reference. Helps to make it easier to read. fwcmd="/sbin/ipfw" # Force a flushing of the current rules before we reload. $fwcmd -f flush # Divert all packets through the tunnel interface. $fwcmd add divert natd all from any to any via tun0 # Allow all connections that have dynamic rules built for them, # but deny established connections that don't have a dynamic rule. # See ipfw(8) for details. $fwcmd add check-state $fwcmd add deny tcp from any to any established # Allow all localhost connections $fwcmd add allow tcp from me to any out via lo0 setup keep-state $fwcmd add deny tcp from me to any out via lo0 $fwcmd add allow ip from me to any out via lo0 keep-state # Allow all connections from my network card that I initiate $fwcmd add allow tcp from me to any out xmit any setup keep-state $fwcmd add deny tcp from me to any $fwcmd add allow ip from me to any out xmit any keep-state # Everyone on the Internet is allowed to connect to the following # services on the machine. This example specifically allows connections # to sshd and a webserver. $fwcmd add allow tcp from any to me dst-port 22,80 in recv any setup keep-state # This sends a RESET to all ident packets. $fwcmd add reset log tcp from any to me 113 in recv any # Enable ICMP: remove type 8 if you don't want your host to be pingable $fwcmd add allow icmp from any to any icmptypes 0,3,8,11,12,13,14 # Deny all the rest. $fwcmd add deny log ip from any to any You now have a fully functional firewall that will allow on connections to ports 22 and 80 and will log any other connection attempts. Now, you should be able to safely reboot and your firewall should come up fine. If you find this incorrect in anyway or experience any problems, or have any suggestions to improve this page, please email me. Questions Why are you using &man.natd.8; and &man.ipfw.8; when you could be using the built in &man.ppp.8; filters? I will have to be honest and say there is no definitive reason why I use ipfw and natd instead of the built in ppp filters. From the discussions I have had with people the consensus seems to be that while ipfw is certainly more powerful and more configurable than the ppp filters, what it makes up for in functionality it loses in being easy to customize. One of the reasons I use it is because I prefer firewalling to be done at a kernel level rather than by a userland program. I get messages like limit 100 reached on entry 2800 and after that I never see more denies in my logs. Is my firewall still working? This merely means that the maximum logging count for the rule has been reached. The rule itself is still working, but it will no longer log until such time as you reset the logging counters. You can reset the logging counters with the ipfw resetlog command. Alternatively, you may increase the log limit in your kernel configuration with the option as described above. You may also change this limit (without recompiling your kernel and having to reboot) by using the net.inet.ip.fw.verbose_limit &man.sysctl.8; value. If I am using private addresses internally, such as in the 192.168.0.0 range, could I add a command like $fwcmd add deny all from any to 192.168.0.0:255.255.0.0 via tun0 to the firewall rules to prevent outside attempts to connect to internal machines? The simple answer is no. The reason for this is that natd is doing address translation for anything being diverted through the tun0 device. As far as it is concerned incoming packets will speak only to the dynamically assigned IP address and not to the internal network. Note though that you can add a rule like $fwcmd add deny all from 192.168.0.4:255.255.0.0 to any via tun0 which would limit a host on your internal network from going out via the firewall. There must be something wrong. I followed your instructions to the letter and now I am locked out. This tutorial assumes that you are running userland-ppp, therefore the supplied rule set operates on the tun0 interface, which corresponds to the first connection made with &man.ppp.8; (a.k.a. user-ppp). Additional connections would use tun1, tun2 and so on. You should also note that &man.pppd.8; uses the ppp0 interface instead, so if you start the connection with &man.pppd.8; you must substitute tun0 for ppp0. A quick way to edit the firewall rules to reflect this change is shown below. The original rule set is backed up as fwrules_tun0. &prompt.user; cd /etc/firewall /etc/firewall&prompt.user; su Password: /etc/firewall&prompt.root; mv fwrules fwrules_tun0 /etc/firewall&prompt.root; cat fwrules_tun0 | sed s/tun0/ppp0/g > fwrules To know whether you are currently using &man.ppp.8; or &man.pppd.8; you can examine the output of &man.ifconfig.8; once the connection is up. E.g., for a connection made with &man.pppd.8; you would see something like this (showing only the relevant lines): &prompt.user; ifconfig (skipped...) ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1524 inet xxx.xxx.xxx.xxx --> xxx.xxx.xxx.xxx netmask 0xff000000 (skipped...) On the other hand, for a connection made with &man.ppp.8; (user-ppp) you should see something similar to this: &prompt.user; ifconfig (skipped...) ppp0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 (skipped...) tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1524 (IPv6 stuff skipped...) inet xxx.xxx.xxx.xxx --> xxx.xxx.xxx.xxx netmask 0xffffff00 Opened by PID xxxxx (skipped...)
diff --git a/en_US.ISO8859-1/articles/diskless-x/article.sgml b/en_US.ISO8859-1/articles/diskless-x/article.sgml index b76978749e..7a58b55a55 100644 --- a/en_US.ISO8859-1/articles/diskless-x/article.sgml +++ b/en_US.ISO8859-1/articles/diskless-x/article.sgml @@ -1,351 +1,362 @@ %man; + + +%trademarks; ]>
Diskless X Server: a how to guide Jerry Kendall
jerry@kcis.com
28-December-1996 1996 Jerry Kendall + + &tm-attrib.freebsd; + &tm-attrib.3com; + &tm-attrib.microsoft; + &tm-attrib.sun; + &tm-attrib.general; + + With the help of some friends on the FreeBSD-hackers list, I have been able to create a diskless X terminal. The creation of the X terminal required first creating a diskless system with minimal utilities mounted via NFS. These same steps were used to create 2 separate diskless systems. The first is altair.example.com. A diskless X terminal that I run on my old 386DX-40. It has a 340Meg hard disk but, I did not want to change it. So, it boots from antares.example.com across a Ethernet. The second system is a 486DX2-66. I setup a diskless FreeBSD (complete) that uses no local disk. The server in that case is a Sun 670MP running - SunOS 4.1.3. The same setup configuration was needed for both. + &sunos; 4.1.3. The same setup configuration was needed for both. I am sure that there is stuff that needs to be added to this. Please send me any comments. Creating the boot floppy (On the diskless system) Since the network boot loaders will not work with some of the TSR's - and such that MS-DOS uses, it is best to create a dedicated boot floppy + and such that &ms-dos; uses, it is best to create a dedicated boot floppy or, if you can, create an MS-DOS menu that will (via the config.sys/autoexec.bat files) ask what configuration to load when the system starts. The later is the method that I use and it works great. My MS-DOS (6.x) menu is below. <filename>config.sys</filename> [menu] menuitem=normal, normal menuitem=unix, unix [normal] .... normal config.sys stuff ... [unix] <filename>autoexec.bat</filename> @ECHO OFF goto %config% :normal ... normal autoexec.bat stuff ... goto end :unix cd \netboot nb8390.com :end Getting the network boot programs (On the server) Compile the net-boot programs that are located in /usr/src/sys/i386/boot/netboot. You should read the comments at the top of the Makefile. Adjust as required. Make a backup of the original in case it gets foobar'd. When the build is done, there should be 2 MS-DOS executables, nb8390.com and nb3c509.com. One of these two programs will be what you need to run on the diskless server. It will load the kernel from the boot server. At this point, put both programs on the MS-DOS boot floppy created earlier. Determine which program to run (On the diskless system) If you know the chipset that your Ethernet adapter uses, this is easy. If you have the NS8390 chipset, or a NS8390 based chipset, use - nb8390.com. If you have a 3Com 509 based chipset, + nb8390.com. If you have a &t3com; 509 based chipset, use the nb3C509.com boot program. If you are not sure which you have, try using one, if it says No adapter found, try the other. Beyond that, you are pretty much on your own. Booting across the network Boot the diskless system with out any config.sys/autoexec.bat files. Try running the boot program for your Ethernet adapter. My Ethernet adapter is running in WD8013 16bit mode so I run nb8390.com C:> cd \netboot C:> nb8390 Boot from Network (Y/N) ? Y BOOTP/TFTP/NFS bootstrap loader ESC for menu Searching for adapter.. WD8013EBT base 0x0300, memory 0x000D8000, addr 00:40:01:43:26:66 Searching for server... At this point, my diskless system is trying to find a machine to act as a boot server. Make note of the addr line above, you will need this number later. Reset the diskless system and modify your config.sys and autoexec.bat files to do these steps automatically for you. Perhaps in a menu. If you had to run nb3c509.com instead of nb8390.com the output is the same as above. If you got No adapter found at the Searching for adapter... message, verify that you did indeed set the compile time defines in the Makefile correctly. Allowing systems to boot across the network (On the server) Make sure the /etc/inetd.conf file has entries for tftp and bootps. Mine are listed below: tftp dgram udp wait nobody /usr/libexec/tftpd tftpd /tftpboot # # Additions by who ever you are bootps dgram udp wait root /usr/libexec/bootpd bootpd /etc/bootptab If you have to change the /etc/inetd.conf file, send a HUP signal to inetd. To do this, get the process ID of inetd with ps -ax | grep inetd | grep -v grep. Once you have it, send it a HUP signal. Do this by kill -HUP <pid>. This will force inetd to re-read its config file. Did you remember to note the addr line from the output of the boot loader on the diskless system? Guess what, here is where you need it. Add an entry to /etc/bootptab (maybe creating the file). It should be laid out identical to this: altair:\ :ht=ether:\ :ha=004001432666:\ :sm=255.255.255.0:\ :hn:\ :ds=199.246.76.1:\ :ip=199.246.76.2:\ :gw=199.246.76.1:\ :vm=rfc1048: The lines are as follows: altair the diskless systems name without the domain name. ht=ether the hardware type of ethernet. ha=004001432666 the hardware address (the number noted above). sm=255.255.255.0 the subnet mask. hn tells server to send client's hostname to the client. ds=199.246.76.1 tells the client who the domain server is. ip=199.246.76.2 tells the client what its IP address is. gw=199.246.76.1 tells the client what the default gateway is. vm=... just leave it there. Be sure to setup the IP addresses correctly, the addresses above are my own. Create the directory /tftpboot on the server it will contain the configuration files for the diskless systems that the server will serve. These files will be named cfg.ip where ip is the IP address of the diskless system. The config file for altair is /tftpboot/cfg.199.246.76.2. The contents is: rootfs 199.246.76.1:/DiskLess/rootfs/altair hostname altair.example.com The line hostname altair.example.com simply tells the diskless system what its fully qualified domain name is. The line rootfs 199.246.76.1:/DiskLess/rootfs/altair tells the diskless system where its NFS mountable root filesystem is located. The NFS mounted root filesystem will be mounted read only. The hierarchy for the diskless system can be re-mounted allowing read-write operations if required. I use my spare 386DX-40 as a dedicated X terminal. The hierarchy for altair is: / /bin /etc /tmp /sbin /dev /dev/fd /usr /var /var/run The actual list of files is: -r-xr-xr-x 1 root wheel 779984 Dec 11 23:44 ./kernel -r-xr-xr-x 1 root bin 299008 Dec 12 00:22 ./bin/sh -rw-r--r-- 1 root wheel 499 Dec 15 15:54 ./etc/rc -rw-r--r-- 1 root wheel 1411 Dec 11 23:19 ./etc/ttys -rw-r--r-- 1 root wheel 157 Dec 15 15:42 ./etc/hosts -rw-r--r-- 1 root bin 1569 Dec 15 15:26 ./etc/XF86Config.altair -r-x------ 1 bin bin 151552 Jun 10 1995 ./sbin/init -r-xr-xr-x 1 bin bin 176128 Jun 10 1995 ./sbin/ifconfig -r-xr-xr-x 1 bin bin 110592 Jun 10 1995 ./sbin/mount_nfs -r-xr-xr-x 1 bin bin 135168 Jun 10 1995 ./sbin/reboot -r-xr-xr-x 1 root bin 73728 Dec 13 22:38 ./sbin/mount -r-xr-xr-x 1 root wheel 1992 Jun 10 1995 ./dev/MAKEDEV.local -r-xr-xr-x 1 root wheel 24419 Jun 10 1995 ./dev/MAKEDEV If you are not using &man.devfs.5; (which is the default in FreeBSD 5.X), you should make sure that you do not forget to run MAKEDEV all in the dev directory. My /etc/rc for altair is: #!/bin/sh # PATH=/bin:/ export PATH # # configure the localhost /sbin/ifconfig lo0 127.0.0.1 # # configure the ethernet card /sbin/ifconfig ed0 199.246.76.2 netmask 0xffffff00 # # mount the root filesystem via NFS /sbin/mount antares:/DiskLess/rootfs/altair / # # mount the /usr filesystem via NFS /sbin/mount antares:/DiskLess/usr /usr # /usr/X11R6/bin/XF86_SVGA -query antares -xf86config /etc/XF86Config.altair > /dev/null 2>&1 # # Reboot after X exits /sbin/reboot # # We blew up.... exit 1 Any comments and all questions welcome.
diff --git a/en_US.ISO8859-1/articles/euro/article.sgml b/en_US.ISO8859-1/articles/euro/article.sgml index 683793499a..f0906e4801 100644 --- a/en_US.ISO8859-1/articles/euro/article.sgml +++ b/en_US.ISO8859-1/articles/euro/article.sgml @@ -1,347 +1,355 @@ %man; + + +%trademarks; ]>
The Euro symbol on <systemitem class="osname">FreeBSD</systemitem> Aaron Kaplan
aaron@lo-res.org
2002 2003 The FreeBSD Documentation Project $FreeBSD$ + + &tm-attrib.freebsd; + &tm-attrib.general; + + This document will try to help you in getting started with the new Euro Symbol on your new keyboard that you had to buy in early 2002 because of the switch to the new common currency. We will first focus on the more important parts like being able to correctly display the symbol on the console. Later sections will deal with configuring particular programs like X11. Lots of helpful input came from Oliver Fromme, Tom Rhodes and countless others. Thanks! Without you this article would not have been possible! The Euro in a nutshell If you already feel comfortable with localization as described in the FreeBSD Handbook you might be only interested in the following facts which will get you started quickly: ISO8859-15 This is a slight modification of the commonly used ISO8859-1 character map. It includes the Euro symbol. Used for the LANG, LC_CTYPE environment variables. iso15-8x16.fnt The &man.vidcontrol.1; font for the console /usr/share/syscons/keymaps/*.iso.kbd Appropriate keyboard maps depending on your language. Set your keymap entry in rc.conf to one of these. LC_CTYPE Used to specify the correct character type in your locale. XkbLayout "lang(euro)" XFree86 config option. /usr/X11R6/lib/X11/fonts/*/fonts.alias Be sure to adapt your X11 fonts to -*-..-*-iso8859-15 A general remark In the following sections we will often refer to ISO8859-15. This is the standard notation starting with FreeBSD 4.5. In older versions, the standard notation was either ISO_8859-15 or DIS_8859-15. If you are using an older version of FreeBSD, be sure to take a look at /usr/share/locale/ in order to find out which naming convention is in place. The console Setting up your console font Depending on your console resolution and size you will need one of the following lines in rc.conf: font8x16="iso15-8x16.fnt" # from /usr/share/syscons/fonts/* font8x14="iso15-8x14.fnt" font8x8="iso15-8x8.fnt" This will effectively select the ISO8859-15 also known as Latin-9 font. ISO8859-15 is a variation of ISO8859-1. You can tell the difference between the two by looking at the Euro symbol: its decimal value is 164. In ISO8859-1 you will notice a circle with four little strokes at the corners. This is often termed the universal currency symbol. In ISO8859-15, instead of the little circle, you have the Euro Symbol. Otherwise the fonts are more or less identical. As of the time of this writing the only usable font seems to be iso15-8x16.fnt. The others seem to only show ISO8859-1 even though the name suggest otherwise. By specifying this font some console applications will look garbled. This is due to the fact that they assume you are using a different font/character set such as ANSI 850. One notable example is sysinstall. However most of the time this should not be of much concern. As the next step you should either reboot your system to let the changes take effect or (manually) take the steps that would have been taken at the system startup: &prompt.user; vidcontrol -f iso15-8x16.fnt To check if the font has been selected execute the following short awk script: #!/usr/bin/awk -f BEGIN { for(i=160;i<180;i++) printf"%3d %c\n",i,i } The result should reveal the Euro sign at position 164. Setting up your keyboard for the Euro Most keyboard maps should already be set up correctly. I.e: If you have a german keyboard and your Umlaut keys are working, you can safely skip this section since the keyboard already maps whatever key combination is necessary (e.g.: Alt Gre) to decimal value 164. If running into problems, the best way to check is to take a look at /usr/share/syscons/keymaps/*.kbd. The format of the key mapping files is described in &man.keyboard.4;. &man.kbdcontrol.1; can be used to load a custom keymap. Once the correct keyboard map is selected, it should be added to /etc/rc.conf with the line: keymap="german.iso" # or another map As stated above, this step has most probably already been taken by you at installation time (with sysinstall). If not, either reboot or load the new keymap via &man.kbdcontrol.1;. To verify the keyboard mapping, switch to a new console and at the login prompt, instead of logging in, try to type the Euro key. If it is not working, either file a bug report via &man.send-pr.1; or make sure you in fact chose the right keyboard map. At this stage the Euro key will not yet work in bash or tcsh. Fixing the environment variables The shells (bash, tcsh) revert to the &man.readline.3; library which in turn respects the LC_CTYPE environment variable. LC_CTYPE must be set before the shell is completely running. Luckily it suffices to add the line: export LC_CTYPE=de_DE.ISO8859-15 to your .bash_profile (bash), or: setenv LC_CTYPE de_DE.ISO8859-15 to your .login (tcsh) file. Of course, de_DE should be replaced by your language. Next, log out, log back in again, and verify your Euro key is working. By now most console applications should respond to the Euro key. Extra configuration steps for special programs like pine might still be necessary however. An alternative to modifying .login and .bash_profile is to set the environment variables through the &man.login.conf.5; mechanism. This approach has the advantage of assigning login classes to certain users (e.g. French users, Italian users, etc) in one place. Modifying X11 Modify /etc/XF86Config in the following manner: Option "XkbLayout" "de(euro)" Again, replace de with your language. By now, the keyboard should be set up correctly. As in the console section, the correct font must be chosen. For KDE, go to the KDE control center -> Personalization -> Country & Language -> Charset and change it to ISO8859-15. Similar steps apply to kmail and other applications. Another good idea is to modify your fonts.alias files. Notably the fixed font should be changed to the right character set: The author's /usr/X11R6/lib/X11/fonts/misc/fonts.alias looks like this: ! $Xorg: fonts.alias,v 1.3 2000/08/21 16:42:31 coskrey Exp $ fixed -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-15 variable -*-helvetica-bold-r-normal-*-*-120-*-*-*-*-iso8859-15 (...) As in the console sections, special applications still have ISO8859-1 fonts configured in their respective &man.xrdb.1; databases. One notable example is xterm. As a general rule of thumb it suffices to change the corresponding configuration file in /usr/X11R6/lib/X11/app-defaults and add the correct font. Let us demonstrate this with xterm. &prompt.root; cd /usr/X11R6/lib/X11/app-defaults/ &prompt.root; vi XTerm Add the following line to the beginning of the file: *font: -misc-fixed-medium-r-normal-*-*-120-*-*-c-*-iso8859-15 Finally, restart X and make sure, fonts can be displayed by executing the above awk script. All major applications should respect the keyboard mapping and the font settings. Open problems Of course, the author would like to receive feedback. In addition, at least let me know if you have fixes for one of these open problems: Describe alternative way of setting up XFree86: x11/xkeycaps Settings in GNOME Settings in XFCE Settings for (X)Emacs Describe UTF-8 Describe libiconv as a effective way to convert between ISO8859-15 and UTF-{8,16} from within applications