The lines for Fedora Core 3 (updated May 2005) are:
[base] name=Fedora Core ITC $releasever - $basearch - Base baseurl=http://linuxload.itc.virginia.edu/export/Fedora3/$basearch [updates-released] name=Fedora Core ITC $releasever - $basearch - Released Updates baseurl=http://linuxload.itc.virginia.edu/export/Fedora3/updates [uva rpms] name=Fedora Core $releasever - $basearch - UVA RPMs baseurl=http://linuxload.itc.virginia.edu/export/Fedora3/uva The legacy site for Fedora Core 2 is [legacy-updates] name=fc2 legacy updates baseurl=http://download.fedoralegacy.org/fedora/2/updates/i386/
You can see exactly what ITC has available by going to
http://linuxload.itc.virginia.edu/export/
When yum is installed, it puts a file in /etc/cron.daily named yum.cron
Edit this file so it looks like:
#!/bin/sh /usr/bin/yum -R 10 -e 0 -d 0 -y update yum /usr/bin/yum -R 120 -e 0 -d 0 -y update tail /var/log/yum.log | mail -s YUM.your.pc yourid@virginia.eduThis will run yum every night and mail you the tail end of the log file showing what happened. Change YUM.your.pc and yourid@virginia.edu to your PC's name and your e-mail ID.
Install yum (if needed) by mounting
linuxload.itc.virginia.edu:/export/Fedora2 /fedora2 nfs noauto,soft 0 0
YUM is in the /fedora2/i386/Fedora/RPMS directory (assuming you mounted it at /fedora2).
Get updates with the
yum update
A HP printer with a Jetdirect card can be accessed directly by creating a remote LPD queue. Make the remote host the IP address of the Jetdirect card and make the remote queue "raw". This is documented in the HP JetDirect Print Servers 600N/400N/500X/300X Administrator's Guide on page 63 in the chapter named "Configuring for LPD Printing".)
Run batch processes hourly, daily, weekly or monthly
Under /etc are directories /etc/cron.daily, cron.weekly, et al. that contain batch scripts that are run periodically.
Examples
mkdir /somepath
mkdir /somepath/home1
smbmount //home1/yourid /somepath/home1 \
-o username=eservices\\yourid,ip=home1.virginia.edu
rpm -aq --queryformat "%10{SIZE} %-30{NAME}\n" | sort -n > size.txt
/dev/hda1 /home ext3 defaults,usrquota 1 2
[Paths] Desktop=/home/rtg2t/kdeDesktop Trash=/home/rtg2t/kdeDesktop/Trash/and create the directory /home/rtg2t/kdeDesktop.
When you use NIS for logon authentication, you have a user database
on a NIS server and multiple Linux machines validate logins from that
central server.
The home directory for that user
must be valid and that is commonly done via an NFS mount to all these
client machines.
With RedHat FC3, you need to install ypbind
and ypserv on the NIS server and
ypbind on each client.
You need to run "authconfig" once on each NIS client machine.
Follow the instructions in Section 7 and 9 of the NIS HOW-TO document.
The trickiest step is mastering the syntax for the /var/yp/securenets
file.
The files to edit in /etc are yp.conf (client) and ypserv.conf (server).
Pick a domain name that doesn't match the DNS name of the server, for security
enhancement.
Add a NIS user
Add the user on the NIS server. Be sure to make the home directory on a
drive that is NFS mounted on all client nodes. For example:
mount /dev/home1 /home1 # on server
# makes the user daffy on the NIS server
useradd -u 54321 -g 100 -d /home1/daffy daffy
passwd daffy
cd /var/yp # on server
make # on server
Now this user can log into any NIS client node.
This user can change her password on any node by typing the command
yppasswd
To prevent ICMP errors from showing up in the syslog, add
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
to /etc/sysctl.conf
Then type
sysctl -p /etc/sysctl.conf
to load in sysctl settings from /etc/sysctl.conf
Use the mkbootdisk command like: mkbootdisk --device=/dev/fd0 2.4.18-5
where 2.4.18-5 is the kernel version and the program reads from
/lib/modules/2.4.18-5 for all the info it needs.
With the help of Bryan Wright in Physics and Olaf Pors at ITC, I setup a
Dell Poweredge 2600 server with production backup.
It runs Linux RH FC2 and serves files with Samba. I'll call it BIG.SEAS.
It has a RAID that can hold up several hundred gigabytes of user stuff.
It is backed up by ITC. Because of the huge disks and to minimize backup
resources, ITC only does a monthly backup. Every day, when I go home, I
turn on a Red Hat Linux machine in my office in a second building. Call
it LITTLE.SEAS. Little has an 80GB drive that is NFS mounted on BIG.
On BIG, I run a job at 2am that does an incremental backup (source at the
end). There are several ways to do this.
DRAWBACK:
The way I chose has the drawback/feature of not detecting files that are
deleted on BIG. They are not erased on LITTLE. This makes a bit of work
for users in case of a catastrophic failure. In case of failure, their
most recently used files are available in minutes from LITTLE.
ADVANTAGES:
1. I can do load balancing to move logical units (directory trees) around
to stay within ITC's limit of 20GB per backup unit.
2. I don't have to keep the entire drive on LITTLE. After running this
system for 75 days, the daemon has only copied 12GB to LITTLE out of about
120GB on BIG. After 90 days, I can delete stuff on LITTLE that is older
than 60 days......
3. Part of backup is to zip all DOC, PPT, XLS, TXT, TEX, AI, and FM files
to a separate zip file each night. Does any one have problems with
corrupted Office files?
CRON JOB SOURCE on BIG
======================
mount /backup/b
# make directories on /backup/b that are new on /p0
find /p0 -size -500000k -type d -mtime -3 -exec mkdir /backup/b'{}' ';'
# copy files from p0 to /backup/b
find /p0 -type f -size -500000k -mtime -3 -exec cp -u -v {} /backup/b'{}' ';'
# check for HUGE files so you can urge users to move it to CDROM
find /home0 -type f -size +300000k -exec ls -ls '{}' ';'
# this the zip operation.
# On 2-Jan-2004 it creates ppt.doc.xls2004.1.2.zip
find /p0 -type f -mtime -3 | \
egrep -i "tex$|ai$|fm$|ppt$|doc$|xls$|txt$" | \
zip /backup/b/office/ppt.doc.xls`date +%Y.%m.%d`.zip -@
umount /backup/b
JOB to DELETE FILES that haven't been changed in 90 days on LITTLE.SEAS
=======================================================================
cd /backup/b
find p0 -type f -mtime +90 -exec rm -f -v '{}' ';'
ITC's METHOD of BREAKING UP HUGE LOGICAL DRIVES
===============================================
If you have a large group of users that all have home directories on
/home, do this:
Put N users on /home0, and make a pointer on /home that points to /home0.
ex: ln -s /home0/rtg2t /home/rtg2t
Do this for /home0 through /home55
When /home0 gets close to 20GB, add another physical drive to the hot-swappable
RAID, create /home56, and move an appropriate number of users on /home0 to
/home56
cd /home/www/html mkdir centos4.1 cd centos4.1 nice -n 19 wget -r -nH --no-parent http://www.gtlib.gatech.edu/pub/centos/4.1/os/i386/Then you can make a boot CDROM from
This process involves two machines:
* a client machine client.example.domain, which is the one from
where the connection and login is started.
* a server machine server.example.domain, running the ssh daemon,
and to where the login attempt is directed.
This is a one way operation, so you need to repeat these steps from
the server machine if you want to have automatic login from the server
to the client. Note that this is not necessarily a desirable idea, for
instance if the server is a firewall machine, you probably do not want
automatic authentication on internal machines, as this simply helps
somebody who has broken into the firewall machine.
Creating Keys
On the client.example.domain machine, user1 runs the command
ssh-keygen -t rsa
to generate the public and private keys, using the RSA algorithm. I
used all the default values, and no pass phrase. This is less secure
than using a pass phrase, but is more convenient. Your call as to the
risk/benefit to you. [If you use a pass phrase, you will be prompted
for it each time you use ssh or scp which does rather negate the
effect of automatic login. However, it does mean that compromise of
your password on the client, or somebody with the root password
(administrator access on Windows), does not gain access to other
machines using your ID.]
The above creates a pair of files in the ~user1/.ssh directory. These
are the public (id_rsa.pub) and private (id_rsa) keys which ssh uses
for authentication. The public key needs to be replicated to all
servers where you wish to login. The private key is used on the client
machine only and should not be copied around. It must be kept private,
and to enforce this, ssh will refuse to use it unless it is readable
(or readable and writable) only by the owner (i.e. mode 400 or
600). The owner of the file must be user1.
Distributing The PUBLIC Key
Copy the file id_rsa.pub to the server.example.domain machine (e.g. by
using scp) and add it to the file ~user1/.ssh/authorized_keys2
file. If this file exists, add the new data to the end, otherwise
create the file mode 644. The safest way to do this is to use the
commands
cat id_rsa.pub >> ~user1/.ssh/authorized_keys2
chmod 644 ~user1/.ssh/authorized_keys2
Note that the ~user1/.ssh/authorized_keys2 file consists of very long
lines, one line per client machine configured to automatically login
to this machine. Using a text editor with line and/or word wrap will
split these long lines, and make the file contents useless!
And that's it.
For added security, you can add from="client.machine.edu" at the front
of the id-rsa entry
rsync --verbose -e ssh -r --update --progress --stats /data1/ \
xxxxxxxxxxx@yyyyyyyyy.zzz.virginia.edu:/aaaa
to backup /data1/ on the client to /aaaa on the server
As an extra level of security you can add a filter on the server
account to restrict non-password access to one client. Take the contents of the
id_rsa.pub file created on the client and edit it from
ssh-rsa AAAi---long-key-string---zsi7c= rtg2t@xxx.yyy.Virginia.EDU to from="xxx.yyy.Virginia.EDU" ssh-rsa AAAi---long-key-string---zsi7c= rtg2t@xxx.yyy.Virginia.EDUCaution: Use an editor that WILL NOT WRAP the text. This all is one long line.
Add a new rule with the command iptables -I RH-Firewall-1-Input -p udp -m udp --dport 514 -s curie.seas.virginia.edu -j ACCEPT this will allow remote syslogging from curie.seas service iptables save This will save all the iptables rules to /etc/sysconfig/iptables
On the receiver machine ----------------------- * Edit /etc/sysconfig/syslog so the syslog parameters are "-m 0 -r -x" and restart syslog with "service syslog restart" * Add a iptables entry to block upd packets from port 514 except from machines that are logging to the receiver On the logging machine ---------------------- Edit /etc/hosts and put the receiver machine Edit /etc/syslog/conf and pick a type of log entry that will be logged remotely and add it. Use ONLY tabs for white space. Ex- local6.err @curie.seas.virginia.edu * Restart syslog with "service syslog restart"