Ben Ruset » Linux

Linux-like bash prompt in OSX

Ben Ruset — Fri, 18 Sep 2009 18:13:02 +0000

For those of us who use bash on our MacOSX boxes as well as Linux (at least RedHat systems) and are annoyed that OSX's bash prompt doesn't look like Linux's, adding these lines to your .profile will fix it. This will enable color for ls as well as change the actual prompt to match RHEL's.

Add these lines to the top of your .profile:

export PS1="[\u@\h \W]$"
export CLICOLOR=1
export LSCOLORS=ExFxCxDxBxegedabagacad

Linux to Active Directory Authentication (Part 1)

Ben Ruset — Thu, 30 Oct 2008 04:12:01 +0000

For a while now I've been meaning to write an article on how to easily set up your Linux boxes to authenticate against an Active Directory setup. I've had this working in production environments for a while now, having cobbled together bits and pieces from various websites, blogs, and trial and error experimentation.

First of all, you're going to need a Windows 2000 Server or Windows Server 2003 system with Active Directory and Microsoft Services for UNIX installed. SFU provides things like extensions to LDAP to make this work, an NFS server, and bits and pieces of other stuff that you probably wouldn't ever care about. If you're using Windows Server 2003 R2 or Windows 2008 then you don't need to worry about SFU comes as part of the base operating system.

Second of all, you're going to need a Linux system. I have done all of my testing with CentOS 4 and 5, which means that it will work for real Red Hat Enterprise Linux servers as well as Oracle Enterprise Linux, if you're one of the five people out there running it. The configuration files below will work fine for either version, so you won't have any problems there.

I'm going to give you a very, very basic config to look at which, later in the article, I will explain why you won't want to use in production. In a (very) soon to be written follow-up article I'll give you some more information on how to make it production ready.

For your Linux machines, you're going to want to make sure that you have the ncsd and nss_ldap packages installed. OpenLDAP should get installed in a default installation, but if you're using a custom kickstart that does not include it, you'll want to install it. On CentOS systems it's as easy as yum'ming it in. On RedHat systems you'll either need to use up2date (if you have a RHN subscription) or manually install it from your media.

The way that LDAP works is when you log in with a user on your Linux box, it will query your LDAP server (in this case your Domain Controllers) to see if you are a valid user, and if you're providing a valid password. On Linux (OpenLDAP) and Windows 2000 servers, this query can be run anonymously - without having to supply some form of credentials to the server to specify that you have rights to do the lookup. Microsoft (rightly) changed the default behavior in Windows 2003 to require a user to bind to Active Directory to do the lookup. So the first order of business is to create a domain user that can be used to query your Active Directory. This user just needs rights in the Domain Users security group. They should not get Administrator access. In my examples this user is called "binduser" and has a password of "password". You should be able to lock this user down so they can not actually log in from any station. (I'll need to test that.)

On your Linux machine, edit the file /etc/ldap.conf, and replace the contents with this. Note the comments in-line:

host your.domain.controller # If you have multiple LDAP servers, separate them with a space.


base cn=Users,dc=domain,dc=com

# If your AD domain is called "foo.com" then the LDAP base is cn=Users,dc=foo,dc=com

# If you're like me, you store users in various OU's, so you could have your base be something further up or down

# the tree, such as:

# base dc=domain,dc=com (to include everything)

# base cn=Sales,dc=domain,dc=com

# base cn=Development,dc=domain,dc=com

# etc.

binddn cn=binduser,cn=Users,dc=domain,dc=com

# This is the important bit. This is where it's going to look to find that user that it will use to look at your AD.

# I store mine in the default "Users" OU, if you put yours elsewhere, you'll need to adjust that as needed

bindpw password

# Since the password is stored in plaintext on your servers you're going to want to use some throwaway

# password for this user.

scope sub

# # Active Directory Mappings # # Since Microsoft doesn't use the same sort of naming scheme for account names, passwords, or other LDAP # attributes as OpenLDAP we need to provide some sort of translation. Here's where we tell Linux to look for # various things in AD. Most importantly the username for the user is found at the attribute sAMAccountName pam_login_attribute sAMAccountName pam_filter objectclass=User pam_password ad pam_member_attribute msSFU30PosixMember nss_base_passwd dc=domain,dc=com nss_base_shadow dc=domain,dc=com nss_base_group dc=domain,dc=com nss_map_objectclass posixAccount User nss_map_objectclass shadowAccount User nss_map_attribute uid sAMAccountName nss_map_attribute uidNumber msSFU30UidNumber nss_map_attribute gidNumber msSFU30GidNumber nss_map_attribute cn sAMAccountName nss_map_attribute uniqueMember member nss_map_attribute userPassword msSFU30Password nss_map_attribute homeDirectory msSFU30HomeDirectory nss_map_attribute loginShell msSFU30LoginShell nss_map_attribute gecos name nss_map_objectclass posixGroup Group nss_map_attribute uniqueMember msSFU30PosixMember nss_map_attribute cn cn

Now, open up the file /etc/openldap/ldap.conf and edit it thusly:

HOST your.domain.controller # If you have multiple LDAP servers, separate them with a space. BASE dc=domain,dc=com

Now, edit the file /etc/nss/nsswitch.conf. This is going to tell Linux where to look for user authentication. Make sure the passwd, shadow, and group lines look like this. It will check for local users first, and then go to LDAP if there is no local user.

passwd: files ldap compat shadow: files ldap compat group: files ldap compat

One handy thing would be to have Linux auto-create a home directory from the /etc/skel templates for a user that logs in via LDAP for the first time. You can edit the /etc/pam.d/system-auth file and edit it so it looks like this:

auth required /lib/security/$ISA/pam_env.so auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok auth sufficient /lib/security/$ISA/pam_ldap.so use_first_pass auth required /lib/security/$ISA/pam_deny.so


account     required      /lib/security/$ISA/pam_unix.so broken_shadow

account     sufficient    /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet

account     [default=bad success=ok user_unknown=ignore] /lib/security/$ISA/pam_ldap.so

account     required      /lib/security/$ISA/pam_permit.so
password    requisite     /lib/security/$ISA/pam_cracklib.so retry=3

password    sufficient    /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow

password    sufficient    /lib/security/$ISA/pam_ldap.so use_authtok

password    required      /lib/security/$ISA/pam_deny.so

session required /lib/security/$ISA/pam_limits.so session required /lib/security/$ISA/pam_unix.so session required /lib/security/$ISA/pam_mkhomedir.so skel=/etc/skel/ umask=0077 # sets home dir perms to 700 session optional /lib/security/$ISA/pam_ldap.so

Now, don't rush to log in as a Windows user yet. You'll need to give them access via Services for UNIX. On the domain controller that you have SFU installed on, go to Active Directory Users and Computers and edit the properties for the user. There should be a tab that says "UNIX Attributes." Select that, and then put them in the NIS domain of your organization, assign them a UID, a default shell, and you should be set.

Try logging in as the user. It may be a bit slow depending on your network and the speed of your machines, but if all goes right the user will authenticate and get a home directory made for them (with the proper umask!)

So, remember before when I said that you don't want to use this in production? Well, think of what happens when you log in. The system presents you with a prompt for your username. Fine, you enter that in. Then it asks you for your password. It then takes both of them and goes up to your domain controller and says "Here's user X does he exist? Fine. Here's his password" sent in cleartext over the wire. Fortunately, you can use SSL to encrypt that exchange so your password does not get sent around to the nearest sniffer. I'll be covering that in a (soon to be written) future article as it's a bit tricky to get set up right.

I'd love to hear from other people doing this in their environments. Feel free to send me a comment and let me know if I am missing any information or if there's anything not very clear.

Going Green

Ben Ruset — Wed, 15 Oct 2008 03:56:38 +0000

Since "green" is in, I've decided to do my part.

1. My AppleTV has turned out to be a disappointment. Even with XBMC loaded, I couldn't get my nfs shares mounted. Unplugged.

2. Since my AppleTV is unplugged, there's less of a compelling reason to keep my home "server" up all the time. All it does is export a 1TB usb drive via NFS and run an irc session in screen every great while. I can easily plug the usb drive into my Mac when I want to access that data. Unplugged.

Okay, lets plug the drive into the Mac. Shit, OSX doesn't support ext3 partitions. Oh well, there's a userland filesystem driver last updated in 2006 that I can load. This will work grea... oh, my Mac locked up when I tried to mount it. Well, I guess I can just pull the 500gb or so worth of data off, move it somewhere else (some combination of my 80gb USB drive, my 250gb USB drive, my 120gb laptop drive, and who knows, maybe even the 4GB SSD in my eee.)

Currently I have my 80GB drive and my 1TB drive mounted in Windows XP in VMware with XP kernel level drivers for ext3 working nicely, and transferring data. This may qualify as one of the most hooptie ways I've ever had to do anything.

I am sure I'll lose something important.

Oh, and I take the bus to work now instead of driving. That makes me green with nausea.

Productive Day

Ben Ruset — Tue, 23 Sep 2008 02:15:44 +0000

Today I finally managed to get RHEL5 boxes authenticating against Active Directory using secure LDAP. I had no problem getting RHEL4 boxes to do it, or RHEL5 boxes without TLS, but I figured out what the problem was with RHEL5. In my /etc/ldap.conf I had a line:

ssl yes

Which enabled Secure LDAP in RHEL4. In RHEL5 the line needs to be:

ssl start_tls

Incidentally, that line works fine in RHEL4, which means that I can continue using the same config files (and eventually package them up as an RPM or something for when we provision new nodes) across RHEL4 and RHEL5 systems.

Beyond that Chris managed to get two Itanium HPUX servers racked and their console cards configured. He had a nice introduction to Wireshark to get their MAC address, and then arp ping to configure the IP's. Tomorrow I will work with him to get the VLANs set correctly on the switch uplinks, and then I will have to do something to jog my memory to disable Serviceguard on those two nodes.

Oracle and Linux Pre-Requisites

Ben Ruset — Fri, 01 Aug 2008 02:20:56 +0000

As a sysadmin, I like to make sure that my servers are as lean as possible. I'm of the philosophy that less is more, and when I build servers, I typically limit the packages that I install to the bare minimum, and add only what I need. The net is a system with fewer running services by default, less disk space used, and less vectors for attack.

Oracle, on the other hand, suggests that - when you build a Linux server (and we're speaking in Red Hat specifics here) - you should take the default set of RPMs. A minimal install of RHEL clocks in at somewhere around 700MB. A default install of RHEL works out to be much larger (I want to say around 7GB, but I'm not 100% sure -- I know it's in the multi-GB range) and includes a bunch of things that you wouldn't want on your Oracle server like a full blown Gnome Desktop, Apache, and Samba Server.

So, what if you decide to do a minimal install of Red Hat, load Oracle, and then add missing dependencies yourself? Well, Oracle's official answer is that you need to reinstall Linux. They offer this flawed analogy to explain their stance. I will bold some of the more braindead verbage. This comes from Metalink note 376183.1:

All Oracle development, coding, testing, documentation, certification and support experience for Oracle on RHEL is based upon this "foundation" of a "default-RPMs" installation of RHEL AS/ES. In the same way that you would not expect the wood framing for a tudor-style house to fit on a ranch-style concrete foundation, please do not expect the Oracle RDBMS software to successfully install upon a "less-than-default-RPMs" foundation of RHEL AS/ES.

At this point, a common question is “Why can’t I just fix the wrong foundation of Linux that I already have? Why do I have to re-install Linux? Or continuing the analogy above, “Why can’t I just go down to the local hardware store, rent a jackhammer, buy a couple of bags of instant concrete, and MAKE it fit?

The answer is “experience”. In the experience of Oracle Global Support, you will continue to experience an infinite series of “installation” or “patching” or “instructions not working” or “GUI tool” or “stability” problems until you re-build this system. Customers who have tried to “just fix it” invariably spend days and in some cases even weeks of frustration before they just “do the right thing” and re-install the correct foundation of Linux.

You would not allow your concrete contractor to try to MAKE your brand-new house fit onto his mistake. In the same way, do not allow yourself to try to MAKE your brand-new Oracle RDBMS installation fit onto the Linux mistake of a "less-than-default-RPMs" installation. Additional RPMs (beyond any documentation) may be needed if a "less-than-default-RPMs" installation of RHEL AS/ES is performed. Oracle Support Services has no experience to advise you on what these additional RPMs may be.

A more cynical translation of that is that Oracle support is lazy, and doesn't want to take the time to tell you what packages and libraries are needed to run their product. It's far easier to tell you to install everything then give you a list of exact prerequisites. Also, you're probably a terrible systems administrator who wouldn't be able to install the necessary RPM's anyway, given our lack of effort at generating a list.

It is absolutely astounding to me that an Enterprise-grade software vendor would not give you a list of packages that are required to install their software on Linux. Interestingly enough, though, the instructions for installing it on Solaris gives you a package by package list of what needs to be installed.

CentOS 4.6 VMWare Server Kickstart

Ben Ruset — Tue, 18 Mar 2008 03:11:51 +0000

As promised, this is the kickstart that I'm using for my Dell PowerEdge 1950's. Setting up and configuring kickstart is beyond the scope of this article (but may be covered in a later one). You will probably want to tweak the partitioning setup to suit your own taste. We're ordering our servers with an 80GB boot/OS drive, and a 750GB drive just to hold VMWare Virtual Machines.

This kickstart will get you a minimal CentOS 4.6 install, with some useful tools, and all of the pre-reqs met for VMWare Server 1.0.4 as well as Dell OpenManage. I am sure it could be whittled down further, but disk is cheap and it's served me well so far.

install
network --device=eth0 --bootproto=dhcp
url --url http://fqdn.of.server.com/osprov/media/Linux/CentOS46-AMD64/
reboot
text
lang en_US.UTF-8
langsupport --default en_US.UTF-8 en_US.UTF-8
keyboard us
mouse none
skipx
rootpw --iscrypted
firewall --disabled
selinux --disabled
authconfig --enableshadow --enablemd5
timezone America/New_York
bootloader --location=mbr

# Partitioning
# This sets the 80GB SATA boot drive to hold /boot, rootfs, and swap
# and sets the 750gb SATA drive to hold VMWare VM's at /var/lib/vmware
clearpart --all --initlabel
part /boot --size=128 --ondisk=sda
part / --size=1024 --grow --fstype=ext3 --ondisk=sda
part swap --recommended --ondisk=sda
part /var/lib/vmware --size=1024 --grow --fstype=ext3 --ondisk=sdb

%packages --resolvedeps
kernel
e2fsprogs
ntp

#VMWare Server Deps
perl
xinetd
gcc
make
kernel-devel
xorg-x11-libs.i386
zlib-devel
zlib-devel.i386
compat-db
compat-db.i386
compat-glibc
compat-glibc.i386
compat-glibc-headers
compat-libstdc++-33
compat-libstdc++-33.i386
compat-libstdc++-296.i386

#Dell OpenManage Deps
audit-libs.i386
cracklib.i386
cracklib-dicts.i386
libxml2.i386
#glib2-2.4.7-1.i386
glib2.i386
#libselinux-1.19.1-7.4.i386
libselinux.i386
#ncurses-5.4-13.el4.i386
ncurses.i386
pam.i386

%post
rpm -i http://fqdn.of.server.com/osprov/media/VMWare/VMware-server-1.0.4-56528.i386.rpm
wget http://fqdn.of.server.com/osprov/media/VMWare/VMware-mui-1.0.4-56528.tar.gz -O /tmp/VMware-mui-1.0.4-56528.tar.gz

#Dell Yum Repository (OpenManage, etc.)
wget -q -O - http://linux.dell.com/repo/hardware/bootstrap.cgi | bash
wget -q -O - http://linux.dell.com/repo/software/bootstrap.cgi | bash

ntpdate pool.ntp.org