Trouble finding a program in a Yum repo?

Use this command to find the file inside of a package.

$ yum whatprovides "*executable"

Such as:

$ yum whatprovides "*uuencode"
sharutils-4.6.1-2.x86_64 : The GNU shar utilities for packaging and unpackaging shell archives.
Repo : base
Matched from:
Filename : /usr/bin/uuencode

Updating clients after moving a Ghost server

We recently moved our Symantec Ghost Console server to a new machine with a new hostname and a new IP address. This meant that all of our client machines would still be looking for the old server hostname. Unfamiliar with how the client communicated with the server, our original plan was to just put in a DNS A record which would point the old server hostname to the new server’s IP address. After getting the new server up we discovered that this would not work. Everything we read online indicated that the clients would have to be uninstalled and re-installed to connect to the new server. Not good. We have about 300 machines and this would be a daunting task to undertake. Ghost provides a method to mass install the client, but this only works when the client is not already installed on a remote machine. The ability to uninstall through the console is there but you cannot select multiples, it’s one at a time. Forget that. I had a thought in the begining that I could write some sort of batch script to perform an uninstallation with the msi and some command line switches and use psexec to run it against all of our client machines. While starting to research this theory I came across a Symantec article which explained how to “Bind a client to a different console”. This method involves replacing the pubkey.crt file on the client with the pubkey.crt file from the new server, or if you only have one server just delete the pubkey.crt file from the client and it will connect to the first Ghost server it finds and create the file itself. Perfect. So I write my batch script to do a net stop on the Ghost client service, delete the pubkey.crt, start the Ghost client service, and be on my merry way. I used the handy psexec tool to remote execute the script on my text file list of hosts and whallah, all of my clients are now in the new Ghost console.

The script:
@echo off
net stop "Symantec Ghost Client Agent"
del "%systemdrive%\Program Files\Symantec\Ghost\pubkey.crt"
net start "Symantec Ghost Client Agent"


psexec syntax:
psexec @hostnames_sw.txt -c ghost.bat > ghost_fix.log

Checking for DFS replication backlog between servers

When using DFS replication there may be times where a backlog of files has built up, usually caused by a member being offline for an extended period of time.   To see how many files are backlogged, and a listing of the latest 100 files in the queue you can use the dfsrdiag command line utility.  This utility should be run from one of the replication members.

If I had two servers, StayPuffed and DontCrossTheStreams and these servers had a replication group named KeyMaster and a folder named Gatekeeper.  If StayPuffed was offline for two days and once brought back up I wanted to check the backlog I would issue the following.

dfsrdiag backlog /rgname:KeyMaster /rfname:Gatekeeper /sendingmember:DontCrossTheStreams
 /receivingmember:StayPuffed

jailing a ftp user with proftpd

If you want to give ftp access to a certain subdirectory on your Linux box, but restrict that user from being able to read anything else on the filesystem you can do so using proftpd

Download the tarball and extract the archive

curl ftp://ftp.proftpd.org/distrib/source/proftpd-1.3.2.tar.gz | tar xz

Now it’s the standard ./configure, make, make install routine

After installing open the config file.  On Redhat you will find it at /usr/local/etc/proftpd.conf

Uncomment the line #DefaultRoot ~

This will cause your users to be “jailed” into their home directory, any other directory can be specified here if desired

Make note of the User and Group values, these will need to exist on your system for the server to start

Also note the setting Limit SITE_CHMOD which is set to DenyAll by default, this will keep ftp users from being able to change file or directory permissions

Remove or comment out all lines in the Anonymous section to prevent anonymous ftp connections

Save and exit the config file.  You should now be able to start the ftp server

/usr/local/sbin/proftpd

You should be able to log in with any local account username and password, and your home directory will be listed.  You should not be able to CD to the parent directory or any other directory outside of your home directory.

Now, the purpose of setting up a ftp in this manor is to restrict access to the rest of your filesystem.  If you create Linux accounts for ftp users they will by default have shell access to the server.  The following steps will allow you to deny shell access to the user while still allowing them to log into the ftp server.

Create a file called /bin/ftpaccess with the following contents

#!/bin/bash
echo "This account is for ftp access only"

Give the file execute permissions

chmod a+x /bin/ftpaccess

Add the file to your list of shells, usually found at /etc/shells

Change the user’s default shell to your newly created “shell”

usermod -s /bin/ftpaccess ftpuser

This user should not be able to log into the shell either locally or via SSH/telnet

Limiting a Linux account to SFTP only

If you need to allow a user to connect to your Linux server with SFTP but do not want to give them the ability to log in via SSH you can do the following:

Add the user account and set the home directory to where you want their root directory to be.

useradd -d /path/to/files/ username

Set the user’s password

passwd username

Modify the user’s shell to use the “sftp-server” shell included in the lib directory (path may vary)

usermod -s /usr/libexec/openssh/sftp-server username

Add the “sftp-server” shell to your system shells

echo ‘/usr/libexec/openssh/sftp-server’ >> /etc/shells

or

vim /etc/shells and add the path manually

The user should now be allowed to login via SFTP only.