cvs commit: hints dhcpcd.txt

timothy at linuxfromscratch.org timothy at linuxfromscratch.org
Mon Jul 8 06:53:38 PDT 2002


timothy     02/07/08 06:53:38

  Modified:    .        dhcpcd.txt
  Log:
  Updates by author.
  
  Revision  Changes    Path
  1.6       +194 -216  hints/dhcpcd.txt
  
  Index: dhcpcd.txt
  ===================================================================
  RCS file: /home/cvsroot/hints/dhcpcd.txt,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- dhcpcd.txt	23 Jun 2002 16:52:43 -0000	1.5
  +++ dhcpcd.txt	8 Jul 2002 13:53:38 -0000	1.6
  @@ -1,216 +1,194 @@
  -TITLE:          DHCP client daemon
  -LFS VERSION:    3.3 (should work on older versions if bootscrips are updated)
  -AUTHOR:         D.J. Lucas <dj_me at swbell.net>
  -		Last updated 06/22/2002
  -
  -SYNOPSIS:       How to setup a DHCP client daemon. This is used with most
  -                networking gateways for cable modems and xDSL modems.  Also
  -                used, nowadays, on almost all corporate networks to set up
  -                non mission critical servers and most workstations.
  -
  -HINT:  After reading the dhcpd hints by Simon Perreault <nomis80 at videotron.ca>
  -and Thinus Pollard <thinusp at olienhout.org.za>, I had an excelent grasp on the
  -configuration and use of dhcpcd.  I, however, felt the need to expand on their
  -ideas and incorporate the use of the DHCP client into the network (ethnet on
  -previous versions) init script.  This will both reduce the amount of scripts in
  -/etc/rc.d/init.d/, and also allow for an easy change back to a static network
  -should the need arise.
  -
  -NOTE:  Just a basic reminder....because this works on my system, dosen't mean
  -that it will work on yours, tho it should.  Even though these are just script
  -changes, IT IS ALWAYS A GOOD IDEA TO BACKUP any existing files that will be
  -changed, deleted, modified, moved, etc....    Also, I do not go into any of
  -the advanced options for cable/*DSL modems that may be required by some ISPs.
  -These options are covered in the man-pages for the client, however, if you are
  -having problems with broadband modems, look for the -D, -H, -I, and -i switches.
  -
  -
  -
  -How to install and configure the DHCP client daemon according to the LFS
  -standards.
  -
  -1. Get the current version of dhcpcd at ftp://ftp.phystech.com/pub/
  -2. Unpack the archive and install.
  -
  -tar -zxf dhcpcd-1.3.22.pl1.tar.gz
  -cd dhcpcd-1.3.22.pl1
  -cp pathnames.h pathnames.h.bak
  -sed 's/"\/etc\/dhcpc"/"\/var\/run\/dhcpc"/' pathnames.h.bak > pathnames.h
  -./configure --prefix=""
  -make
  -make install
  -
  -NOTE:  Command explanations, we do not want to install dhcpcd in prefix=/usr
  -because in a lot of systems, usr is network mounted.  Also, this is not a 
  -program that we'd have most users access, so it makes sense to me to install
  -in /sbin. However, It's your lfs do what you like.  The sed command edits the
  -pathnames that are built into the source so dhcpd puts the state files and pid
  -files correctly in a dhcpc subdir under /var/run.  This was added to make sure
  -that cleanfs correctly removes the pid files when the system is restarted 
  -without being properly shut down.
  -
  -NOTE:  Although not recomended, if you are using a version older than
  -dhcpcd-1.3.22-pl1, see the previous dhcp hints (dhcpd.txt and dhcpd2.txt) at:
  -http://hints.linuxfromscratch.org/hints/old/ .
  -
  -3. Create the new device specific scripts.
  -Per a little help from Gerard: there is no longer any need to edit the existing
  -scripts to allow for new network device types.  This is built into the first 
  -if statement in both the $network_scripts/ifup and $network_scripts/ifdown 
  -files.  So now we will create the $nework_devices/ifup-eth? and 
  -$network_devices/ifdown-eth? files. This method proves to be a much 
  -easier method for new device types that weren't accounted for in the base 
  -build.  Also, we now will not mess with your existing config files, so should 
  -you need to return to a static assigned IP, we can simply delete the script 
  -we've changed. In the following example, we are creating a script for eth0, 
  -if you need for eth1, copy the files to ifup-eth1 an ifdown-eth1 respectively, 
  -and edit for eth1.
  -______________________________________________________________________________
  -cat > /etc/sysconfig/network-devices/ifup-eth0 << "EOF"
  -#!/bin/sh
  -# Begin /etc/sysconfig/network-devices/ifup-eth0
  -
  -source /etc/sysconfig/rc
  -source $rc_functions
  -
  -echo "Bringing up the eth0 interface via DHCP..."
  -/sbin/dhcpcd eth0
  -evaluate_retval
  -# End /etc/sysconfig/network-devices/ifup-eth0
  -EOF
  -_______________________________________________________________________________
  -cat > /etc/sysconfig/network-devices/ifdown-eth0 << "EOF"
  -#!/bin/sh
  -# Begin /etc/sysconfig/network-devices/ifdown
  -
  -source /etc/sysconfig/rc
  -source $rc_functions
  -
  -echo "Bringing down the eth0 interface..."
  -/sbin/dhcpcd -k eth0
  -evaluate_retval
  -
  -# End /etc/sysconfig/network-devices/ifdown
  -EOF
  -chmod 755 /etc/sysconfig/network-devices/ifup-eth0
  -chmod 755 /etc/sysconfig/network-devices/ifdown-eth0
  -______________________________________________________________________________
  -
  -4. Bootscrpt handling.
  -
  -Another issue has come to surface with the way LFS handles shutdowns and
  -restarts in the new scripts.  By default, in runlevel 0 and runlevel 6, network
  -is called as K80, this causes a problem because dhcpcd is exacly as it's name
  -implies, a daemon.  In both of these runlevels, sendsignals is run at K50,
  -before the network script has a chance to run, therefore, the dhcp client
  -daemon is killed by the time the script runs.  I don't know if this is a good
  -idea or not, but it works for what little I have on my system.  It seems to me
  -that a lot of network services that will possibly be installed will be daemons,
  -and that sendsignals should be run after the network is properly shut down.
  -I'd appreciate any feedback that anybody could give on this statement.  Run
  -the following commands to eliminate this problem as I have.
  -------------------------------------------------------------------------------
  -mv /etc/rc.d/rc0.d/K80network /etc/rc.d/rc0.d/K45network
  -mv /etc/rc.d/rc6.d/K80network /etc/rc.d/rc6.d/K45network
  -______________________________________________________________________________
  -
  -As you can see, this will run the network script at K45, prior to sendsignals
  -at K50, eliminating this problem.  There may be other problems that surface if
  -you do not move network dependent Kills before K45 on some systems.  This may
  -not be the ideal solution for all systems.  It's your own LFS, check it out.
  -It has also been suggested that sendsignals should be moved to K70 (moving 
  -everything currently behind it as well to allow for more room between the K40
  -and K50. This is up to you, again, it's your LFS system, do what you like!
  -
  -5.  Changes to /etc/sysconfig/network
  -
  -Note:  You may notice that there is no change to the way the default
  -gateway is setup.  Also, that there is no change to the network script itself.
  -This is because dhcpcd handles the route setup internally if a default gateway
  -is provided by the DHCP server.  If a card configured via DHCP is given a
  -default gateway by the DHCP server, then that card is automatically put into
  -the routing table as a default route.  There is currently no way to turn this
  -feature off.  I'm not sure as to why you would actually need to turn it off,
  -but I thought it was worth mentioning.
  -
  -You only need to chage the /etc/sysconfig/network file if the default
  -route device is now being configured by DHCP.  If your default route device is 
  -now set up by DHCP, then you'll need to comment out (#) the "GATEWAY" and the 
  -"GATEWAY_IF" variables.  Make a backup copy and fix it with the following:
  -_______________________________________________________________________________
  -cd /etc/sysconfig
  -cp network network.bak
  -sed 's/GATEWAY/# GATEWAY/' network.bak > network
  -_______________________________________________________________________________
  -
  -6.  What to do with your /etc/hosts file.
  -
  -On most systems it should not be necessary to do the following, but I have 
  -recieved questions reguarding specific aplications.
  -THE FOLLOWING IS NOT RECOMENDED UNLESS YOU KNOW EXACTLY WHAT YOU ARE DOING.
  -I'll leave it up to the reader to edit/create the scripts to do this.
  -You can source the variables in the /var/run/dhcpc/dhcpcd-$1.info file after
  -the interface is set up, and then dynamicly write (appended) to the hosts file.
  -If you have the need to do this, create an additional script that runs only on
  -startup (in the same runlevels as network) that deletes the hosts file, gets
  -the necessary info from the dhcpcd-$1.info file's variables, creates a new
  -hosts file, and writes to that hosts file (appended) from a static copy of the
  -permanent entries.  I may edit this how-to in the future to include info on
  -this process, but not untill I've had a chance to test ALL of the failsafes.
  -This is currently out of the scope of this document, however, feedback on this
  -idea would be much appreciated.  
  -
  -Addendum to the above statement: I now think that I'll NOT add instructions on
  -this method, as a good script should be able to source the dhcpcd-$1.info file
  -for use by itself without needing to make any update to the current config
  -files.  Something more to think about if you had asked about this previously.
  -
  -7.  Before you reboot you need to test the system.  Start by running ifconfig
  -with no options to see which devices are enabled.  Disable all devices except
  -lo by running:
  -_______________________________________________________________________________
  -ifconfig <device name> down
  -_______________________________________________________________________________
  -
  -Now start the network using the following command:
  -_____________________________________________________________________________
  -/etc/rc.d/init.d/network start
  -_____________________________________________________________________________
  -
  -Look for any failures and try to track them down.  If you have no failures,
  -run ifconfig and make sure everything looks okay.  Also check that your
  -routing is set up correctly by running route with no argurments.  If
  -everything looks good, then stop the network.
  -_____________________________________________________________________________
  -/etc/rc.d/init.d/network stop
  -_____________________________________________________________________________
  -
  -Again look for any failures and track them down.  Again run route and ifconfig,
  -and look for any interfaces that aren't supposed to be there.  If there are no
  -interfaces, besides lo, returned by ifconfig and there are no routes set,
  -congratulations.  Reboot your system and continue on your path with LFS.
  -If you do have failures that you cannot track down.  Please feel free to
  -e-mail me <dj_me at swbell.net>  be sure to include the full problem description
  -(as much as you understand), the exact error message, and the text of all
  -your config files.  If you have problems, you've made a backup of everything,
  -so put the backups back where you got them from.
  -
  -8.  Conclusion:  "I hope this helps somebody out there ;)" -- Thinus Pollard
  -I'd like to thank Thinus Pollard and Simon Perreault for their versions of
  -this hint....which had my LFS system up and running in under an hour.  I'd
  -also like to thank the following dedicated LFS users who took the time to track
  -down the problems in my first version of this hint.
  -
  -Special thanks to: Robert Smol, Rich Jones, Phil Gendreau, Cli - corrected 
  -dhcpcd -k $Device, Markku Tikkanen, Tijmen Stam - provided cable modem info,
  -Steve Hayashi, Wolfgang Scheicher - provided dhcpcd default gateway and routing
  -info, Carl Spelkens - corrected the runlevels before I even wrote this hint,
  -and Oliver  - proper fix for correcting the locations of the state 
  -and pid files.
  -
  -
  -The new scripts in 3.3+ have disolved quite a few of the issues encountered in
  -my previous hint. So a big thanks to Gerard!  As always, please send any tips.
  -suggestions, flames...etc, to dj_me at swbell.net or just edit this hint yourself.
  -
  --- D.J. Lucas <dj_me at swbell.net>
  +TITLE:          DHCP client daemon
  +LFS VERSION:    3.3 (should work on older versions if bootscrips are updated)
  +AUTHOR:         D.J. Lucas <dj_me at swbell.net>
  +		Last updated 06/22/2002
  +
  +SYNOPSIS:       How to setup a DHCP client daemon. This is used with most
  +                networking gateways for cable modems and xDSL modems.  Also
  +                used, nowadays, on almost all corporate networks to set up
  +                non mission critical servers and most workstations.
  +
  +HINT:  After reading the dhcpd hints by Simon Perreault <nomis80 at videotron.ca>
  +and Thinus Pollard <thinusp at olienhout.org.za>, I had an excelent grasp on the
  +configuration and use of dhcpcd.  I, however, felt the need to expand on their
  +ideas and incorporate the use of the DHCP client into the network (ethnet on
  +previous versions) init script.  This will both reduce the amount of scripts in
  +/etc/rc.d/init.d/, and also allow for an easy change back to a static network
  +should the need arise.
  +
  +NOTE:  Just a basic reminder....because this works on my system, dosen't mean
  +that it will work on yours, tho it should.  Even though these are just script
  +changes, IT IS ALWAYS A GOOD IDEA TO BACKUP any existing files that will be
  +changed, deleted, modified, moved, etc....    Also, I do not go into any of
  +the advanced options for cable/*DSL modems that may be required by some ISPs.
  +These options are covered in the man-pages for the client, however, if you are
  +having problems with broadband modems, look for the -D, -H, -I, and -i switches.
  +
  +
  +How to install and configure the DHCP client daemon according to the LFS
  +standards.
  +
  +1. Get the current version of dhcpcd at:
  +	ftp://ftp.phystech.com/pub/dhcpcd-1.3.22.pl1.tar.gz
  +2. (optional) Obtain the LFS patch for DHCPCD.
  +	http://www.lucasit.com/linux/dhcpcd-1.3.22.pl1.patch.bz2
  +3. Unpack the archive, patch, and install.
  +bzip2 -d dhcpcd-1.3.22.pl1.patch.bz2
  +tar -zxf dhcpcd-1.3.22.pl1.tar.gz
  +cd dhcpcd-1.3.22.pl1
  +patch -Np1 -i ../dhcpcd-1.3.22.pl1.patch
  +./configure --prefix="" --sysconfdir=/var/lib --mandir=/usr/share/man
  +make
  +make install
  +
  +
  +NOTE:  Command explanations, we do not want to install dhcpcd in prefix=/usr
  +because in a lot of systems, usr is network mounted.  Also, this is not a 
  +program that we'd have most users access, so it makes sense to me to install
  +in /sbin. However, It's your lfs do what you like.  The LFS patch changes the
  +location of the cache, info, and pid files to be both LFS freindly and FHS
  +compliant.  This was added to make sure that cleanfs correctly removes the 
  +pid files when the system is restarted without being properly shut down.
  +
  +4. Create the new device specific scripts.
  +Per a little help from Gerard: there is no longer any need to edit the existing
  +scripts to allow for new network device types.  This is built into the first 
  +if statement in both the $network_scripts/ifup and $network_scripts/ifdown 
  +files.  If you are using a version of LFS prior to 3.3, see my old hint for the 
  +correct scripts.  http://hints.linuxfromscratch.org/hints/old/dhcpcd.txt
  +We will create the $nework_devices/ifup-eth? and $network_devices/ifdown-eth?
  +files. This method proves to be a much easier method for new device types that 
  +weren't accounted for in the base build.  Also, we now will not mess with your 
  +existing config files, so should you need to return to a static assigned IP, 
  +we can simply delete the scripts we've created. In the following example, we 
  +are creating a script for eth0, if you need for eth1, rename the files to 
  +ifup-eth1 and ifdown-eth1 respectively, and edit for eth1.
  +______________________________________________________________________________
  +cat > /etc/sysconfig/network-devices/ifup-eth0 << "EOF"
  +#!/bin/sh
  +# Begin /etc/sysconfig/network-devices/ifup-eth0
  +
  +source /etc/sysconfig/rc
  +source $rc_functions
  +
  +echo "Bringing up the eth0 interface via DHCP..."
  +/sbin/dhcpcd eth0
  +evaluate_retval
  +# End /etc/sysconfig/network-devices/ifup-eth0
  +EOF
  +_______________________________________________________________________________
  +cat > /etc/sysconfig/network-devices/ifdown-eth0 << "EOF"
  +#!/bin/sh
  +# Begin /etc/sysconfig/network-devices/ifdown
  +
  +source /etc/sysconfig/rc
  +source $rc_functions
  +
  +echo "Bringing down the eth0 interface..."
  +/sbin/dhcpcd -k eth0
  +evaluate_retval
  +
  +# End /etc/sysconfig/network-devices/ifdown
  +EOF
  +chmod 755 /etc/sysconfig/network-devices/ifup-eth0
  +chmod 755 /etc/sysconfig/network-devices/ifdown-eth0
  +______________________________________________________________________________
  +
  +5. Bootscrpt handling.
  +
  +Another issue has come to surface with the way LFS handles shutdowns and
  +restarts in the new scripts.  By default, in runlevel 0 and runlevel 6, network
  +is called as K80, this causes a problem because dhcpcd is exacly as it's name
  +implies, a daemon.  In both of these runlevels, sendsignals is run at K50,
  +before the network script has a chance to run, therefore, the dhcp client
  +daemon is killed by the time the script runs.  I don't know if this is a good
  +idea or not, but it works for what little I have on my system.  It seems to me
  +that a lot of network services that will possibly be installed will be daemons,
  +and that sendsignals should be run after the network is properly shut down.
  +I'd appreciate any feedback that anybody could give on this statement.  Run
  +the following commands to eliminate this problem as I have.
  +------------------------------------------------------------------------------
  +mv /etc/rc.d/rc0.d/K80network /etc/rc.d/rc0.d/K45network
  +mv /etc/rc.d/rc6.d/K80network /etc/rc.d/rc6.d/K45network
  +______________________________________________________________________________
  +
  +As you can see, this will run the network script at K45, prior to sendsignals
  +at K50, eliminating this problem.  There may be other problems that surface if
  +you do not move network dependent Kills before K45 on some systems.  This may
  +not be the ideal solution for all systems.  It's your own LFS, check it out.
  +It has also been suggested that sendsignals should be moved to K70 (moving 
  +everything currently behind it as well to allow for more room between the K40
  +and K50. This is up to you, again, it's your LFS system, do what you like!
  +
  +6.  Changes to /etc/sysconfig/network
  +
  +Note:  You may notice that there is no change to the way the default
  +gateway is setup.  Also, that there is no change to the network script itself.
  +This is because dhcpcd handles the route setup internally if a default gateway
  +is provided by the DHCP server.  If a card configured via DHCP is given a
  +default gateway by the DHCP server, then that card is automatically put into
  +the routing table as a default route.  There is currently no way to turn this
  +feature off.  I'm not sure as to why you would actually need to turn it off,
  +but I thought it was worth mentioning.
  +
  +You only need to chage the /etc/sysconfig/network file if the default
  +route device is now being configured by DHCP.  If your default route device is 
  +now set up by DHCP, then you'll need to comment out (#) the "GATEWAY" and the 
  +"GATEWAY_IF" variables.  Make a backup copy and fix it with the following:
  +_______________________________________________________________________________
  +cd /etc/sysconfig
  +cp network network.bak
  +sed 's/GATEWAY/# GATEWAY/' network.bak > network
  +_______________________________________________________________________________
  +
  +7.  Before you reboot you need to test the system.  Start by running ifconfig
  +with no options to see which devices are enabled.  Disable all devices except
  +lo by running:
  +_______________________________________________________________________________
  +ifconfig <device name> down
  +_______________________________________________________________________________
  +
  +Now start the network using the following command:
  +_____________________________________________________________________________
  +/etc/rc.d/init.d/network start
  +_____________________________________________________________________________
  +
  +Look for any failures and try to track them down.  If you have no failures,
  +run ifconfig and make sure everything looks okay.  Also check that your
  +routing is set up correctly by running route with no argurments.  If
  +everything looks good, then stop the network.
  +_____________________________________________________________________________
  +/etc/rc.d/init.d/network stop
  +_____________________________________________________________________________
  +
  +Again look for any failures and track them down.  Again run route and ifconfig,
  +and look for any interfaces that aren't supposed to be there.  If there are no
  +interfaces, besides lo, returned by ifconfig and there are no routes set,
  +congratulations.  Reboot your system and continue on your path with LFS.
  +If you do have failures that you cannot track down.  Please feel free to
  +e-mail me <dj_me at swbell.net>  be sure to include the full problem description
  +(as much as you understand), the exact error message, and the text of all
  +your config files.  If you have problems, you've made a backup of everything,
  +so put the backups back where you got them from.
  +
  +8.  Conclusion:  "I hope this helps somebody out there ;)" -- Thinus Pollard
  +I'd like to thank Thinus Pollard and Simon Perreault for their versions of
  +this hint....which had my LFS system up and running in under an hour.  I'd
  +also like to thank the following dedicated LFS users who took the time to track
  +down the problems in my first version of this hint.
  +
  +Special thanks to: Robert Smol, Rich Jones, Phil Gendreau, Cli - corrected 
  +dhcpcd -k $Device, Markku Tikkanen, Tijmen Stam - provided cable modem info,
  +Steve Hayashi, Wolfgang Scheicher - provided dhcpcd default gateway and routing
  +info, Carl Spelkens - corrected the runlevels before I even wrote this hint,
  +and Oliver Brakmann - provided the patch for correcting the locations of the 
  +state, cache, and pid files.
  +
  +
  +The new scripts in 3.3+ have disolved quite a few of the issues encountered in
  +my previous hint. So a big thanks to Gerard!  As always, please send any tips.
  +suggestions, flames...etc, to dj_me at swbell.net or just edit this hint yourself.
  +
  +-- D.J. Lucas <dj_me at swbell.net>
  +
  +
  
  
  
-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe hints' in the subject header of the message



More information about the hints mailing list