Puppet and Virtual User Creation

I have been using Puppet for more and more admin tasks, and expanding the complexity of what I am doing. Currently, I am doing just about everything in the puppet config files, but am planning on starting to use ENC (initially through Puppet Dashboard, possibly moving to The Foreman). I didn't love the way I was managing users with Puppet, and am in the process of revamping it. I had really needed to virtualize user creation, so that things became manageable. To that end, I found Scott Lowe's Blog on Puppet Account Management, which got me 90% of where I wanted to go. The trick I still wanted to perform was to set an initial password, but not to reset their password after they change it. I had an idea of how to do this using Subscribe, and that at least seems to be working well initially.

define intusers::virtual ($uid,$realname,$pass) {

  user { $title:
    ensure            =>  'present',
    uid               =>  $uid,
    gid               =>  $title,
    shell             =>  '/bin/bash',
    home              =>  "/home/${title}",
    comment           =>  $realname,
#    password          =>  $pass,
    password_max_age => '90',
    password_min_age => '0',
    groups     => ['sudo'],
    managehome        =>  true,
    require           =>  Group[$title],
  }
  group { $title:
    gid               =>  $uid,
  }

  exec { "/usr/sbin/usermod -p \'$pass\' $title":
    refreshonly => true,
    subscribe => User[$title],
    #    logoutput => true,
  }

SMART On Windows

I have long been annoyed by the lack of SMART monitoring available for Windows, and when I had previously looked into this the tools that I found were not terribly good. It seems this has been rectified by the Smartmontools Project, which now compiles and functions under Windows. Orsiris de Jong has done one better, and wrapped some other tools and a better installer along with Smartmontools, configuring smartd to start as a service, adding notifications, etc. His project page is at Netpower.fr/smartmontools.

sudo on Debian Etch

While Debian Etch is horribly out of date, I still have a couple of servers that I administer that require Debian 4.0 aka Etch. One unfortunate bit is that it seems that the version of sudo (1.6.8p12-4) packaged for Etch is horribly broken. Specifically, it does not seem to prompt for a password to give elevated privs. Even when modifying the sudoers file to specifically say authentication is required (via the authenticate Defaults and the PASSWD tag) allows passwordless entry. The fix that I have applied is compiling the sudo package from Lenny sudo source package. The source package is available at Lenny sudo (1.6.9p17-3)

Find and Time

I have never been particularly good at remembering find's arguments related to times/dates/etc. So this is going to be a bit of a cheat sheet for myself. Find *~ files modified older than today:

find . -name \*~ ! -newermt `date +%F -s yesterday`

Find *~ files modified newer than yesterday:

find . -name \*~ -newermt `date +%F -s yesterday`

Find *~ files between certain days:

find . -name \*~ -newermt `date +%F -s '14 days ago'` ! -newermt `date +%F -s '7 days ago'`

Multiple Samba Instances on Separate Interfaces

I didn't find a lot of information on how to have multiple different samba instances running on the same machine, and what I did find didn't seem all inclusive.  So the various configuration directives I needed to set are:

#
#Specify the Interfaces that this instance will listen on for smbd
interfaces = eth0 
#Specify the IP that nmbd will use
socket address = 192.168.1.1
#Only bind the above
bind interfaces only = yes

#The following line may be needed to clear up some connection issues with older clients, and possibly it should be 139 445
smb ports = 139

#
# On at least one instance, the directories for state/cache/locks/etc will need to be changed
state directory = /var/lib/samba-eth3
private dir = /var/lib/samba-eth3
lock directory = /var/run/samba-eth3
pid directory = /var/run/samba-eth3
cache directory = /var/cache/samba-eth3

#
# Logging
# Make sure to fix the log file directive
# log file = /var/log/samba-eth3/log.%m

#
# Authentication
# May need to update passdb backend line to keep separate
passdb backend = tdbsam:/var/lib/samba-eth3/passdb.tdb

Additionally, a startup script will need to be created adding the specific configuration to the commandline for smbd/nmbd. The commandline will be something like:

/usr/sbin/nmbd -D -s /etc/samba-eth3/smb.conf -l /var/log/samba-eth3/
/usr/sbin/smbd -D -s /etc/samba-eth3/smb.conf -l /var/log/samba-eth3/

Do you need Anti-virus on Linux?

I will freely admit I was a naysayer for anti-virus on Linux.  That said, it is a good security policy so I setup and run periodic scans on the linux boxes I admin.  Until today, I had only ever seen Windows viruses sitting in peoples old mbox mailboxes, and given I would need to delete all of their email to address this nothing happened.

Today, that changed.  I was reviewing system messages from over the weekend and I saw an email from the clamscan cronjob I have setup on many servers.  It went a little like:

/tmp/openx-2.8.10/etc/plugins/openXVideoAds.zip: Backdoor.OpenX.CVE_2013_4211 FOUND

..../openads/plugins/deliveryLog/vastServeVideoPlayer/flowplayer/3.1.1/flowplayer-3.1.1.min.js: Backdoor.OpenX.CVE_2013_4211 FOUND

..../openads/plugins/plugins/deliveryLog/vastServeVideoPlayer/flowplayer/3.1.1/flowplayer-3.1.1.min.js: Backdoor.OpenX.CVE_2013_4211 FOUND

..../openads/etc/plugins/openXVideoAds.zip: Backdoor.OpenX.CVE_2013_4211 FOUND

A quick google turned up a link to Packet Storm.  http://packetstormsecurity.com/files/cve/CVE-2013-4211

Where CVE-2013-4211 became an exploit candidate 3 days ago.  I see some other mentions from a few days earlier, but definitely not too long ago.  Since that time, clamav has updated it's definitions, freshclam downloaded them, and I got notified that I had an active backdoor on one of my servers because of maintaining a good anti-virus policy on Linux.

So ends the lesson.

Using ssh's ProxyCommand and netcat to access Servers with no Public IP

It is not unusual to have servers with no public IP address.  In some cases you can access these servers via VPN, or utilize alternate ports for SSH, but sometimes that is just inconvenient and you need to hop through another server.  This can be accomplished using the ssh ProxyCommand configuration directive in ~/.ssh/config, and netcat.

For example, if I can ssh to 'machine-a' and from machine-a can ssh to 'machine-b' I could add the following into my ~/.ssh/config file

Host machine-b
ProxyCommand ssh -q machine-a nc -q0 machine-b 22

I then would use 'ssh machine-b' from the commandline to tunnel through machine-a.