[WBEL-users] Setting up a local WBEL mirror and update area - howto

Ewan Mac Mahon ecm103@york.ac.uk
Sun, 21 Mar 2004 17:22:47 +0000


On Sat, Mar 20, 2004 at 09:15:27PM -0600, Will Senn wrote:
> All,
> 
> Nobody asked me for this, but considering the amount of work it was, 
> perhaps someone will appreciate a recipe. Please feel free to correct 
> anything that isn't accurate or suggest improvements.
> 
Nice, maybe we can get John to put it on the website when he gets back. In the
meantime, however, I have a few suggestions...

<snip>
> 
> Updating to rhn-applet-2.1.7
> 
>    1. download the updated version of the source RPM, available at:
>        
> http://people.redhat.com/~veillard/testing/FC1/i386/rhn-applet/2.1.7/rhn-applet-2.1.7-1.src.rpm
> 
>    2. save the file to  /usr/src/redhat/SRPMS
> 
This assumes that you're going to build the RPM as root, which is
generally considered A Bad Thing(TM). Aside from a few awkward packages
that need root most should be built as an unprivelleged user. It does need
a little setting up, but if I were you I'd just include a pointer to a
guide elsewhere rather than writing my own; there's one at
<http://freshrpms.net/docs/fight/> that covers it, amongst other things.



>    3. install the sources
>       #rpm -ivh /usr/src/redhat/SRPMS/rhn-applet-2.1.7-1.src.rpm
> 
>    4. unzip the source
>       #cd /usr/src/redhat/SOURCES
>       #tar xvzf rhn-applet-2.1.7.tar.gz
> 
More as a matter of style than anything else, I'd have rpm do it for us:
$ rpmbuild -bp SPECS/applet.spec

>    5. find and change the occurances of redhat-release to whitebox-release
>       #cd rhn-applet-2.1.7
>       #grep -n -i redhat-release *
>          when run will return line numbers and filenames of any files 
> containing the string redhat-release
>       #vi +292 rhn_applet_model.py
>       #vi +156 rhn_applet_rpc.py
> 
How about (all one line):

for filename in `grep -l redhat-release *` ; do mv -f ${filename} ${filename}.orig ; sed -e "s/redhat-release/whitebox-release/g" < ${filename}.orig > ${filename} ; rm -f ${filename}.orig ; done

which should do it automatically. To be honest though I'd have thought the
correct approach to this would be for John to release a fixed version -
since he's already including a fedora derived version of up2date I
wouldn't have thought that this would be an unacceptable deviation from
RHEL.

>    6. backup or delete the downloaded SRPM, we do not need it anymore - 
> we are going to create a new, fixed version
>       #rm /usr/src/redhat/SRPMS/rhn-applet-2.1.7-1.src.rpm
> 
rpm will just overwrite it with the new one anyway, so this is redundant
(but harmless)

>    7. rebuild the SRPM
>       #cd /usr/src/redhat/SPECS
>       #rpmbuild --ba applet.spec
> 
>    8. create the optimized RPM for rhn-applet
>       #cd /usr/src/redhat/SRPMS
>       #rpmbuild --rebuild --target i686 rhn-applet-2.1.7-1.src.rpm
> 
>    9. remove the existing rhn-applet
>       #rpm --erase rhn-applet
> 
>    10. install the new rhn-applet
>       #cd /usr/src/redhat/RPMS/i686
>       #rpm -ivh rhn-applet-2.1.7-1.i686.rpm
> 
Umm - wouldn't an upgrade be better than an uninstall/reinstall?

>    11. exit the running applet
>        If you are in X Windows, right-click on the rhn-applet icon 
> (usually a Blue check-mark or Red exclamation-point to the right) and 
> select Exit from the pop-up menu.
> 
>    12. start the new applet
>          click the Foot => System Tools => Red Hat Network Alert Icon
> 
> 
> Create an area for the updates and base os
> 
>    If you have 6+ GB free disk space on a mounted filesystem, you can 
> skip down to step XXXX, otherwise, I am going to cover partitioning and 
> creating the filesystem from free unallocated space on the hard drive.
<snip>

Again, I'd just point to an external HOWTO, lots of people aren't going to
need this, but that's just a matter of personal taste.
 
>    3. create the mount point and ftp directory
>          #mkdir /whitebox
>          #mkdir /var/ftp/pub/whitebox
> 
>    4. create the filesystem for the partition we created above
>          #mke2fs -j -L "/whitebox" /dev/hda11
> 
>    5. create entries for the /whitebox mountpoint and the ftp directory 
> in fstab
>          #vi /etc/fstab
>             LABEL=/whitebox   /whitebox   ext3   defaults   1   2
>             LABEL=/whitebox   /var/ftp/pub/whitebox   ext3   defaults 1
>             0
> 
I'm probably missing something here, but why mount it in two places rather
than just under /var/ftp?

>    6. mount the filesystem to the 2 mount points
>         #mount -a
>             or alternatively
>        #mount /dev/hda11 /whitebox
>        #mount /dev/hda11 /var/ftp/pub/whitebox
> 
>    7. add vsftp to the runlevel(s) and start it up
>       #chkconfig --level 345 vsftpd on
>       #service vsftpd start
>
A 'chkconfig vsftpd on' will work to turn it on in levels 2, 3, 4 & 5
without the --level parameter.
 
>    8. create a directory to hold the base os
>       #mkdir /whitebox/os/i386
> 
>    9. for each of the original 3 cd's - mount them, copy their contents 
> to the base os directory and unmount them
>       #mount /mnt/cdrom
>       #cp -var /mnt/cdrom/* /whitebox/os/i386
>       #umount /mnt/cdrom
> 
>    10. use rsync to sync the base os and retrieve the updates
>       #rsync --quite --delete --recursive 
> mirror.physics.ncsu.edu::whitebox/3.0/en/os /whitebox/
>       #rsync --quite --delete --recursive 
> mirror.physics.ncsu.edu::whitebox/3.0/en/updates /whitebox/
>
Typo - that's 'quiet', not 'quite'.
 
>    11. create a script for cron to call
>       #vi /etc/cron.d/whiteboxupdates
>          #!/bin/sh
>          rsync --quite --delete --recursive 
> mirror.physics.ncsu.edu::whitebox/3.0/en/updates /whitebox/
>       #chmod a+x /etc/cron.d/whiteboxupdates
> 
>    12. edit the crontab to call the whiteboxupdates script every day at 
> 4:20am
>       #crontab -e
>          20   4   * * * /etc/cron.d/whiteboxupdates
> 
Well you could, but just slinging it in /etc/cron.daily is easier.

> 
> Modify the yum.conf and up2date sources files to use the new local mirror
> 
<snip>
 
> Celebrate
> 
>    If the recipe worked, and it should - say yippee and move on to more 
> challenging stuff like securing it all...
> 
Just a thought, and I could well be remembering this wrongly, but doesn't
vsftpd default to not allowing anonymous logins? If it does then how to
change it would be a useful thing to add.


Ewan