This web page is containing a bunch of utilities to deal with miscellaneous issues regarding Unix / Linux software and administration. Their purpose is to fix known problems before a patch is released officially by whatever party should actually do it, or when the maintainer has refused or doesn't agree with the usefulness or need of the modification. Another topic is a best practices collection.
All things found here reflect the personal opinion and experience of me, Albert Flügel (af@muc.de), since several years working in the systems administration and software area. Everything is provided as is, without any warranty, only in source form, so the downloader can review and check, that there are no unwanted exploits or malicious functionality contained. Unless stated differently, all things come under the GNU General Public License Version 3.
There is no common topic, under that this collection can be subsumed. It's just regarding several issues, that came across to me over time and might be helpful to others, too. Their maturity status varies. If something does not work as expected, contributions are welcome, but due to the fact, that i'm quite busy, i cannot commit any degree of responsiveness.
Table of Contents
Samba miscellaneous runtime fixes (samba-rx)
Sendmail patch to avoid NFS root Export
ISCSI and Multipathing devices on Linux
Balancing and Fault Tolerance for TCP-based services
Apache authenticating with login credentials (via PAM)
Desktop session over web without the need for any software on the client
This package is now available on sourceforge, too, so please see also here
The Samba packages coming with RedHat, other Linux distributions or with Solaris are causing a few phenomenons, that can be just annoying or in a certain context showstoppers. The fixes contained in this package can be used to remedy the problems at runtime without modifying the original Samba package. As long as these things are not addressed in the Samba sources, the extensions are provided here. See the README file for more. Downloads:
samba-rx-1.3.tar.gz The Sources
samba-rx-1.3-1.src.rpm The Source RPM
When sendmail should deliver E-Mail to “traditional” mailbox files mounted over NFS (e.g. into users' home directories), a root NFS export to the mail delivery agent host is required since ever. Because root exports are to be considered an security weakness, they should be avoided. This patch modifies the mail.local program (the “local mailer”), so the root export is no longer necessary. For whatever reasons, mail.local performs a different procedure, when the mailbox file is already there, compared to creating the mailbox file. If the file already exists, it changes the effective user id and appends the new mail to the file. If the file does not exist, it creates it (as root !!!) and performs a chown on it. In my opinion there is no reason not do change the effective user id and creating the file like when appending to it. Download:
sendmail-8.14.4.patch.af Patch for all sendmails since at least 8.13.1 until at least 8.14.4
To apply: Unpack the original sendmail sources, cd to the sendmail distribution subdirectory and run:
patch -p 1 < /path/to/sendmail-8.14.4.patch.af
pcnfsd is a daemon being queried by some old simple NFS implementations to verify user credentials and deliver the numerical IDs of the account and the groups it belongs to. Furthermore an interface to BSD and SYSV style printers is provided. It is currently unclear and untested, if this Linux port works with cups and cups-lpd.
Despite of the warnings and concerns expressed in the description section of the spec-file in the source RPM (please read them !): if a pcnfs servivce is still desired, that can work together with current operating systems that use a PAM stack for authentication etc, this source package has been developed putting together all the patches and enhancements i could find in the internet and writing a bit of code to support PAM. Downloads:
pcnfsd-2.2.tar.gz The sources
pcnfsd-2.2-1.src.rpm The source RPM
When setting up ISCSI devices on Linux it is quite likely, that there are several possible network paths (routes) to reach the server containing the target device. If it is desired to have a preferred route or a certain order of routes to use (active-standby), there's no appropriate tooling available on the Internet by the time of this writing (May 2010). So a bit of help can be found here.
The multipathing setup uses a callout program passing it the name of the storage device (e.g. sda or sdc). The program must write a number to standard output representing the priority of this device. Postings on the internet imply, that this called program can be a script, what is not true and surely untested by the posting persons. The program is called by the kernel and not by init or one if it's children. For this reason it must be statically linked. When using an interpreted script or a dynamic binary, there's no error message anywhere, probably confusing entries (e.g. sth like: program XY exited with status 255) in the syslog. Things work, but actually the priorities, the callout program should return, are not applied.
The C-files in this directory can be compiled like shown in the README file to obtain a program usable in the multipath.conf like shown here. The arguments following the %n should contain substrings of the IP-address with decreasing desired priority. E.g. the entry
prio_callout "/sbin/mpath_prio_by_path_ip /dev/%n 192. 172."returns 2 as priority if the network target IP-address of the respective block device /dev/sd? is containing 192. , and 1, if containing 172. If it is not containing any of the strings passed as arguments in the IP-address, 0 is returned to the kernel's multipathing module. If it is desired to assign the priorities in the argument list, it can be given by appending a slash / and the desired proority. To e.g. achive the reverted priorities compared to the example above, write:
prio_callout "/sbin/mpath_prio_by_path_ip /dev/%n 192./1 172./2"
To automatically mount ISCSI-dependent filesystems at boot time, i'd suggest to add them to /etc/fstab like this using the _netdev tag in the options column:
/dev/mpath/mpath0 /path/to/iscsi/mountdir ext3 _netdev,defaults 0 0and use this script to perform the actual mounts. If your Linux distribution already is providing a way to do this: Great. On RHE4 and 5 i did not find any way, if the root filesystem / is residing on an internal disk of the box. The script can be run as soon as the portmapper (required by ISCSI) is up. Probably the line starting with # chkconfig: might require modification, if the portmapper (or "rpcbind") is started later. On RHE5 the starting number of the portmapper's init script is 13.
I really like the GNU licensed program balance program, developped by Thomas Obermair at Inlab (a company providing a commercial version, too), that i extended by three features, i didn't want to do without:
Together with a HA software like heartbeat the balancer itself can be made highly available. A configuration running very successfully has three identically configured samba servers as backend. Two hosts are possible balancers. One of them has a logical IP-address (service-address) with a logical network node name assigned. Both balancer hosts are running the balance program, one of them is thus in standby mode. When the active host dies, the heartbeat software switches the service address to the other host thus taking over the balancing. NB: E.g. for samba this does not make a really uninterrupted service. But it turned out, that mostly the respective outages and reconnects are tolarted in favour of longer lasting outages.
Usually i start the balancer within an init scriptcontaining a section similar to this:
mkdir -p /var/run/balance balance -MA 25 smtp-server1 smtp-server2Then it can be controlled without restart (e.g. disable / enable channels, add new channels) running
balance -Mi 25For more please see the documentation of balance.
If someone is concerned about the number of balancing processes possibly running on one machine: don't worry, hundreds, if not thousands of balance processes can run on a moderately current hardware. The balance program has a very little resource footprint. Sure, the TCP forwarding produces a bit of additional latency. Experience shows, that this is hardly noted at all.
For SSL/TLS-connections a certificate is required. When using a balancing like shown here, the certificates located on the backend servers (!) should have the full qualified logical server name (the client considers the balancer being the server) as "DNS subject alternate name". See e.g. here what this strangely sounding term means. Otherwise clients that are checking the certificates might complain and refuse to accept the service. Download:
This topic is greatly covered here. If this had not been written right the way it is (regarding functionality), i would have started it. I did not check the programming style or whatever coding consideration, so as usual running the software is at everybodies own risk (and fun). Just a few hints here that might help using it.
First of all, please think at least twice, whether you really want users to authenticate to web services with their normal system logon credentials. Security considerations apply, that i do not repeat here once more. After all, there are situations, where it is desirable. E.g. the web login service outlined below. SSL is a must, otherwise the credentials go over the network in cleartext.
This solution includes a module into apache (mod_authnz_external) and makes it call an external program (pwauth) to check username and password. In the following i assume Apache 2.2 and thus mod_authnz_external-3.2.5 being used.
Building the software is straightforward and done like with most of the usual open source Unix packages (see mod_authnz_external-3.2.5/INSTALL and pwauth-2.3.8/INSTALL).
Before building the pwauth program one might want to check, whether the restriction, that it works only being run with a certain set of UIDs, is really desired. Define the preprocessor macro SERVER_UIDS appropriately or comment it out, if you don't want such a check at all. The default is UID 72 only, what on my system is not a registered account at all, so here it would never work with the default build. Unfortunately the program did not output any helpful error message to me (or i'm too stupid), so i had to use the source to find this out.
To configure the mod_authnz_external module add to your httpd.conf file after installation:
LoadModule authnz_external_module modules/mod_authnz_external.so AddExternalAuth pwauth /usr/local/sbin/pwauth SetExternalAuthMethod pwauth pipe(assumed the pwauth program has been installed as /usr/local/sbin/pwauth . Please adapt, if different) Put the follwing lines into a .htaccess file in the respective directory:
AuthType Basic AuthName "Unix Login" AuthBasicProvider external AuthExternal pwauth require valid-userand put the following directive into the Directory stanza, where it should be in effect:
AllowOverride AllIf it is not necessary to have .htaccess files within different directories (what is the normal case, if not several distinct administrators are configuring the webserver), the section specifying the authentication mechanism can be put into the Directory stanze together with the AllowOverride All directive.
This topic is not covered here in more detail, because the package is now available on sourceforge. Please just go here. The package makes use of several techniques mentioned above. Be ready to experience something that until now you got only from (more or less) commercial packages like Exceed on Demand or NX, where you have to install a software on the client to use the functionality.