Chris Cruft

I cannot get chroot’ed home directories to work for normal users -although it works fine with the anonymous user. When the user logs in, he gets the following error:

Screen clipping taken: 28/09/2005, 17:03

If I disable selinux protection for the ftp service (setsebool ftpd_disable_trans 1) and restart vsftpd, the problem goes away. The problem is documented here:

https://www.redhat.com/archives/fedora-selinux-list/2005-August/msg00044.html

Anonymous FTP is a bit tough because it requires configuring selinux and vsftp as well as a couple of utility steps. First, configure vsftp to allow anonymous access by adding the following entry to /etc/vsftpd/vsftpd.conf:

anonymous_enable=YES

#this instructs vsftpd to permit anonymous login (via ftp users named anonymous or ftp)

ftp_username=ftp

#this is the system user for anonymous ftp

Next, the anonymous user needs a “home” directory. FC4 creates the /var/ftp directory and this is a reasonable setting.

Anonymous uploads require even further manipulation. The vsftpd.conf file must include the following directive:

anon_upload_enable=YES

and you need to create a directory where the anonymous user can write files. I choose /var/ftp/incoming with an owner of root:root and permissions of 777. There are lots of limitations that can be placed here with permissions -such as being able to create files but not see them. For now, I’ll keep it simple.

SELinux must also be adjusted. The following boolean needs to be set:

# setsebool allow_ftpd_anon_write 1

In addition, the selinux context of the directory must be adjusted so that selinux will allow writes:

# chcon -t ftpd_anon_rw_t /var/ftp/incoming

And to make it really permanent, you need to add a setting to the /etc/selinux/POLICYTYPE/contexts/files/file_contexts.local file. See the man page for ftpd_selinux for details.

I decided to look further into the FTP failures I have been experiencing. It seems that the failures can be broken into two separate scenarios:

1. Passive Mode

When the FTP client uses passive mode (the default for the Linux FTP client), transfers fail with the client reporting “ftp: connect: No route to host.” The problem stems from the client attempting to open a second, high port on the ftp server (as typically implemented for passive mode operation). Disabling the firewall (service iptables stop) on the server will resolve this problem, but a long-term solution to this problem is documented below.

2. Active Mode

When the FTP client uses active mode, the behavior depends on the client. If the client permits incoming connections to a high port (>1024), everything should work nicely. But if the client does not, the connection will appear to hang. Linux’s iptables firewall will not support such a connection by default. Windows XP does appear to support such a connection. To summarize, the problems with active mode FTP need to be resolved at the client.

Long-term Passive Mode solution:

In order to enable passive mode connections to work, the server must allow incoming connections to negotiated ports above port 1024. One solution would be to configure the ftp server (vsftpd) to use a restricted range of ports and statically configure the firewall to always permit incoming connections to those ports. But this approach is inherently too permissive -the un-protected high ports are not the sole dominion of the ftp server and other (malicious? naive?) applications could use them. A better solution is to use a firewall helper application to monitor the ftp control channel (high port on client<->port 21 on server) and discern dynamically the high port (on the server) to be opened just for the duration of the ftp connection. Such a helper application exists for iptables: ip_conntrack_ftp

To enable it, edit /etc/sysconfig/iptables-config and change this line

IPTABLES_MODULES=”"

to this

IPTABLES_MODULES=”ip_conntrack_ftp”

Problem Solved!

NB: If you use NAT/Masquerading on the iptables firewall, you may need ip_nat_ftp loaded as well. I found it was not necessary with an external (Linksys) NAT firewall.

References:

https://www.redhat.com/archives/fedora-list/2004-December/msg03372.html

http://slacksite.com/other/ftp.html

http://www.sns.ias.edu/~jns/wp/2006/01/24/iptables-how-does-it-work/?p=20

su amanda -c “/usr/sbin/amlabel CCH1 CCH100″

su amanda -c “/usr/sbin/amcheck CCH1″

su amanda -c “/usr/sbin/amdump CCH1″

Works fine for one tape, can’t get others to work correctly.

Matt returned one of the Compaq DLT 35/70 drives (the original one from suzuki) to me as well as my external chassis with the Exabyte 8900 (Mammoth) and HP DDS-2 drive inside.  I installed the drives into triumph and began testing, first with the DLT drive.  Initially all looked good as I tar’ed the /home file system to tape with no errors.  But that was the last operation I could perform on the drive before it failed.  I couldn’t even get the status of the drive without an error.  Even after rebooting the server, the drive is now giving input/output errors.  I am more convinced than ever that this DLT drive is faulty.  Assuming the Quantum 7000 and the Compaq 35/70 are equivalent, I even went so far as to call Quantum support in an attempt to get some help -they were worthless.  The declined to provide specific details on the stinit.def file for the DLT 7000 drive (their example file here shows the values for a DLT 8000) and they also declined to help get their DLT xTalk application working under Linux with a kernel greater than 2.4.7.  Worthless.

Last night I did a dump on my HP DAT 8i (HP model C1533A).  It is a DDS-2 drive with 4GB of native capacity and a nominal 8GB with compression enabled.  This drive used to be connected to my Netware Server.  I bought it new and I was confident that there were no hardware issues.  So I did a dump of some data:

tar cvf /dev/tape1 /home/cch1

and it too spooled the files out to tape with no problem.  This morning, I verified the dump with:

tar tvf /dev/tape1

and everything reported correctly.  Finally, it looks like I have a gold standard against which I can begin measuring the other tape drives.

For the HP C1533A, I have added the following entry to /etc/stinit.def:

Screen clipping taken: 23/09/2005, 11:00

And I have added an appropriate entry to amanda.conf.

References:

http://h20000.www2.hp.com/bizsupport/TechSupport/Home.jsp?&lang=en&cc=us&prodTypeId=12169&prodSeriesId=63916&h_lang=en&lang=en&cc=us

Bluetooth has been showing up on my server in both processes and during boot.  The ProLiant 3000 has no Bluetooth adapters and I don’t think I will ever add one -given that the server also lacks USB ports, it would be challenging.  Here is how to kill the Bluetooth processes:

service bluetooth stop

chkconfig –levels 2345 bluetooth off

To disable the loading of the module, there is probably something to be done in /etc/modprobe.conf -but I can’t yet figure it out.  At run time, it is easy to:

rmmod rfcomm

rmmod l2cap

rmmod bluetooth

I am creating a new installation of amanda on triumph to use the DDS-2 tape drive that is working.  Some relevant facts:

I have lots of tapes!

I doubt I will remember to change tapes every day

The tape capacity is small compared to the volume of data to be backed up

These facts collectively yield the following values in amanda.conf:

1. org “CCH1″

# Name of backup set

2. mailto “amanda”

# User to receive mail reports at

3. dumpcycle 2 weeks

# Number of days in the normal dump cycle

4. runspercycle 10 days

# Number of amdump runs in dumpcycle days

5. tapecycle 18 tapes

# Number of tapes in rotation

# 2 weeks (dumpcycle)

#  x 10/14 of the time remembering to load a new tape

#  + a few extra to handle errors that need amflush

#     and so we do not overwrite the full backups performed

#     at the beginning of the previous cycle

6. tapedev “/dev/nst1″

# Compressing, no-rewind tape device for the HP C1533A

7. tapetype HP-C1533A

# HP SureStore 8i, assuming 120m tapes

8. labelstr “^CCH1[0-9][0-9]*$”

# Tape label format

I also changed some other parameters, including dumptypes and the location where amanda keeps the tape list file to be (/var/lib/amanda/CCH1).

Since it seems that my old HP SureStore 8i drive is the only reliable drive on hand, I am going to set it up for use with amanda.

Screen clipping taken: 23/09/2005, 11:06

I am assuming that 120m tapes will be used and that compression (mode1 via /dev/tape1 or /dev/nst1) will be enabled.  If the stated capacity of the drive with no compression is 4GB (that is, 4,000,000,000 bytes) and we get an average of 1.5:1 compression, the drive should be able to store about 5722 megabytes (that is, 5722 x 1024 bytes).  I’ll run with 5700 megabytes to play it safe.  The speed of the drive is an even more conservative estimate.

I have also found that the firewall (iptables) can cause problems with FTP. I am seeing this error:

Screen clipping taken: 22/09/2005, 15:24

The recommended solution is to disable Passive Mode by issuing the command PASSIVE. Unfortunately, that results in protocol lockups. I suspect the firewalls may have a role in this failure (Linksys or iptable -guilty party to be identified later).

Thanks again to Richard Black’s website (http://www.cpqlinux.com), I have found some worthwhile info on HP’s website.

1. Server Diagnostics are available to update/replace the version that came on the SmartStart CD.

http://h18007.www1.hp.com/support/files/server/us/download/18396.html

2. Smart-2 Controller Firmware update.  Version 4.50 A is available here:

http://h18007.www1.hp.com/support/files/server/us/download/10906.html

While this version may also be present on the monster 7.20 and 7.30 firmware update CDs, I’m thinking the Smart-2 Controllers were too old to be included on the monster CD.

3. Remote Insight Lights Out Edition Firmware Update.  Version 2.53 A (09 March 2004) is available here:

http://h18007.www1.hp.com/support/files/server/us/download/20439.html

Or, if you want to use the monster firmware update CD, here:

http://h18023.www1.hp.com/support/files/server/us/download/22499.html

4. Server System ROM-BIOS updates.  Both versions of the ProLiant 3000 (E39, P09) can be found here:

http://h18023.www1.hp.com/support/files/server/us/romtabl.html

I think I have the latest versions (dated from some time in 2000).

5. The real jackpot will come from getting the ProLiant Support Pack applications  working with the ProLiant 3000:

http://h18023.www1.hp.com/support/files/server/us/download/22262.html

This collection includes drivers for the array controllers, Integrated Lights Out controllers and NICs, the System Management Homepage (hpsmh), the System Health Application and Insight Management Agents (hpasm), array configuration utility (cpqacuxe) and array diagnostics utility (hpadu).  It is not reported to work with the ProLiant 3000 nor Fedora.

6. The entire ROMPaq collection prior to 2002, including a text file documenting each ROMPaq, can be found here:

ftp://ftp.compaq.com/pub/softpaq/