If you notice that your linux machine is holding on to old DNS entries and you are running the nscd service there is a good chance that invalidating (flushing) the NSCD hosts database will help. This is roughly the linux equivalent to ipconfig /flushdns on windows or dscacheutil -flushcache on os x.

nscd -i hosts

From the NSCD man page:

The daemon will try to watch for changes in configuration files appropriate
for each database (e.g.  /etc/passwd for the passwd database or /etc/hosts and
/etc/resolv.conf for the hosts database), and flush the cache when these are
changed.  However, this will happen only after a short delay (unless the
inotify(7) mechanism is available and glibc 2.9 or later is available), and
this auto-detection does not cover configuration files required by nonstandard
NSS modules, if any are specified in /etc/nsswitch.conf.  In that case, you
need to run the following command after changing the configuration file of the
database so that nscd invalidates its cache:
 
$ nscd -i <database>

In most variants of GNU/Linux the init daemon and its configuration file /etc/inittab are used to define things like runlevels and consoles. In an effort to improve boot time, system performance and ease scripted configuration, ubuntu has implemented upstart, an event-based replacement for the traditional init daemon. This is good for the most part, but in different versions ubuntu upstart is configured in different locations which can be quite confusing.

Aside from the change in location, the items that traditionally would be represented by a line in /etc/inittab have been split up into individual files. Despite this difference, the syntax used within the individual files is very familiar.

Where did the ubuntu inittab go?

Here’s where “inittab” lives on different versions of ubuntu.

Ubunutu inittab equivalent for Karmic (9.10) and newer:

Init functionality has been broken out into individual files located in /etc/init.

# ls /etc/init
autofs.conf                  mountall-shell.conf               rsyslog.conf
avahi-daemon.conf            mounted-debugfs.conf              screen-cleanup.conf
console.conf                 mounted-dev.conf                  setvtrgb.conf
console-setup.conf           mounted-proc.conf                 shutdown.conf
container-detect.conf        mounted-run.conf                  ssh.conf
control-alt-delete.conf      mounted-tmp.conf                  statd.conf
cron.conf                    mounted-var.conf                  statd-mounting.conf
cryptdisks-enable.conf       networking.conf                   tty1.conf
cryptdisks-udev.conf         network-interface.conf            tty2.conf
dbus.conf                    network-interface-container.conf  tty3.conf
dmesg.conf                   network-interface-security.conf   tty4.conf
ecryptfs-utils-restore.conf  plexmediaserver.conf              tty5.conf
ecryptfs-utils-save.conf     plymouth.conf                     tty6.conf
failsafe.conf                plymouth-log.conf                 udev.conf
flush-early-job-log.conf     plymouth-splash.conf              udev-fallback-graphics.conf
gssd.conf                    plymouth-stop.conf                udev-finish.conf
hostname.conf                plymouth-upstart-bridge.conf      udevmonitor.conf
hvc0.conf                    portmap-boot.conf                 udevtrigger.conf
hwclock.conf                 portmap.conf                      upstart-socket-bridge.conf
hwclock-save.conf            portmap-wait.conf                 upstart-udev-bridge.conf
idmapd.conf                  procps.conf                       ureadahead.conf
module-init-tools.conf       rc.conf                           ureadahead-other.conf
mountall.conf                rcS.conf                          wait-for-state.conf
mountall-net.conf            rc-sysinit.conf                   mountall-reboot.conf

Ubuntu inittab equivalent for Jaunty (9.04), Feisty (7.04) & Edgy (6.10)

Init functionality is broken out into individual files located in the /etc/event.d/ directory.

/etc/event.d/

Ubunutu inittab for Dapper (6.06) and Earlier

These versions use a standard /etc/init file.

/etc/inittab

After upgrading to Snow Leopard I noticed that when using finder to browse certain directories, especially network file shares, the window would begin scrolling and jumping up and down erratically on its own. I was left scratching my head about this for a while until I finally realized that this only happened when connecting to file shares that we served from hosts that were case sensitive.

Turns out finder freaks out when two files or directories contain the same text but have different case. For example, “test_directory” and “Test_directory”. This is perfectly valid on systems that support case sensitive files but causes odd results in OSX.

The fix that I implemented was to simply identify files and directories whose case would collide in OSX and renamed them accordingly. From a linux system you could use a command like the following to detect and count duplicate files or directories.

ls | tr [:upper:] [:lower:] | sort -n | uniq -cd

This takes the output of ls and uses tr to read everything as lower case, sorts that output and then uses uniq to determine if any duplicates exist.

I haven’t been able to locate a switch in finder to simply enable case sensitivity, if this exists I would love to hear about it

Configuring an amazon EC2 image to associate itself with your puppet master on boot was once an involved manual process requiring custom boot scripts and hand-rolling your own AMI. With the UEC (Ubuntu Enterprise Cloud) AMIs this is much more straightforward. As long as you use an AMI from this list you’ll be able to pass information about the puppet master into the user-data field when booting the instance.

Simply modify the following and place it in the user-data field when booting your instance to automatically connect to your puppet master.

Note: indentation counts!

#cloud-config
#
# This is an example file to automatically setup and run puppetd
# when the instance boots for the first time.
# Make sure that this file is valid yaml before starting instances.
# It should be passed as user-data when starting the instance.
puppet:
 # Every key present in the conf object will be added to puppet.conf:
 # [name]
 # subkey=value
 #
 # For example the configuration below will have the following section
 # added to puppet.conf:
 # [puppetd]
 # server=puppetmaster.example.org
 # certname=i-0123456.ip-X-Y-Z.cloud.internal
 #
 # The puppmaster ca certificate will be available in 
 # /var/lib/puppet/ssl/certs/ca.pem
 conf:
   puppetd:
     server: "puppetmaster.mydomain.com"
     # certname supports substitutions at runtime:
     #   %i: instanceid 
     #       Example: i-0123456
     #   %f: fqdn of the machine
     #       Example: ip-X-Y-Z.cloud.internal
     #
     # NB: the certname will automatically be lowercase as required by puppet
     certname: "%i-%f"
   # ca_cert is a special case. It won't be added to puppet.conf.
   # It holds the puppetmaster certificate in pem format. 
   # It should be a multi-line string (using the | yaml notation for 
   # multi-line strings).
   # The puppetmaster certificate is located in 
   # /var/lib/puppet/ssl/ca/ca_crt.pem on the puppetmaster host.
   #
   ca_cert: |
     -----BEGIN CERTIFICATE-----
     MIICKTCCAZKgAwIBAgIBATANBgkqhkiG9w0BAQUFADAdMRswGQYDVQQDDBJzZXJ2
     ZXIuZGNzdGVhbS5jb20wHhcNMTAwODI4MjAyNTE1WhcNMTUwODI3MjAyNTE1WjAd
     MRswGQYDVQQDDBJzZXJ2ZXIuZGNzdGVhbS5jb20wgZ8wDQYJKoZIhvcNAQEBBQAD
     gY0AMIGJAoGBANvMoMdOBfBWinFsfAIvEhnCHI73AUeAZYuOmIE3FeZwoHDvY/To
     y9zzgVSXTmXE9GSQUiOJ6jq/xFpfClPSGJb+KLDWAt+gCVTI8RaMsFCnyltFpBaP
     KnT6P0nwMrrNgxEpZ2U8qIiqibqOzabcdp3X183N8uQEumnfmhmm8i1ZAgMBAAGj
     eTB3MDgGCWCGSAGG+EIBDQQrFilQdXBwZXQgUnVieS9PcGVuU1NMIEdlbmVyYXRl
     ZCBDZXJ0aWZpY2F0ZTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQwtldWP7Gf
     +469Ywmr8KaM23DEfTALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEFBQADgYEArbaS
     3TZP5Tn+E6Vn8souVD8e4UG1jSeGeb639cGUyMSJBOhKQ0gGYtsmx84cu8wVCXFx
     KfJsWhxWFNZ/0RapuhOg5uGJLDJNuC6QCXRjh/T+Bk1oMNif6noBi6ObhubFRWJd
     e3B9hRPbAaTMg6cpA/3bvQT5LyvwsN4D6VkT4sw=
     -----END CERTIFICATE-----

That’s really all there is to it! Give the machine a few minutes to initialize and soon you will see a new certificate waiting to be signed by puppetca!

Thanks to this post.

Because I refer to the NetApp man pages so frequently I host a copy on this web server at http://backdrift.org/man/netapp/. I Hope you find them useful!

I came across this odd puppet error while setting up a puppet client on a host running in amazon EC2 and it took me a bit of head scratching to figure it out.

(/File[/var/lib/puppet/lib]) Failed to generate additional resources using 'eval_generate': undefined method `closed?' for nil:NilClass
 
(/File[/var/lib/puppet/lib]) Failed to retrieve current state of resource: undefined method `closed?' for nil:NilClass Could not retrieve file metadata for puppet://example.com/plugins: undefined method `closed?' for nil:NilClass
 
Could not retrieve catalog from remote server: undefined method `closed?' for nil:NilClass

The problem was that the host name I used in my puppet.conf file as the puppet server (example.com) did not match the host name (cn) of the puppetmaster CA. A quick update to puppet.conf and everything was working as expected!

Another possible cause for this error is an incorrect puppetmaster CA in your puppet config. In general, this error seems to indicate that something isn’t settling right with SSL.

This is the most complete list of ports used by NetApp filers that I have been able to find to date. It is from the /etc/services file that NetApp provides within their firmware that they have updated to show only services consumed or served by a NetApp filer.

This is taken from Data ONTAP firmware Release 7.2.6.1.

#/vol/vol0/etc/services 
#
# Network services, Internet style
#
 
ftp-data        20/tcp
ftp             21/tcp
ssh             22/tcp
telnet          23/tcp
smtp            25/tcp
time            37/tcp           # Time Service
time            37/udp           # Time Service
domain          53/udp           # DNS
domain          53/tcp           # DNS
portmap         111/udp
portmap         111/tcp
dhcps           67/udp           # DHCP server
dhcpc           68/udp           # DHCP client
tftp            69/udp
http            80/tcp
kerberos        88/udp           # Kerberos 5 
kerberos        88/tcp           # Kerberos 5 
nntp            119/tcp         
ntp             123/tcp          # Network Time Protocol
ntp             123/udp          # Network Time Protocol
netbios-name    137/udp          # NetBIOS nameserver 
netbios-dg      138/udp          # NetBIOS datagram service 
netbios-ssn     139/tcp          # NetBIOS service session 
snmp            161/udp
ldap            389/tcp          # LDAP session
https           443/tcp          # SecureAdmin/SSL
cifs-tcp        445/tcp          # CIFS over TCP with NetBIOS framing
kpasswd         464/tcp          # Filer does not listen on this port;
                                 # used as Domain Controller destination port 
                                 # for Kerberos passwd set/change operations
shell           514/tcp
syslog          514/udp
route           520/udp
ldap-ssl        636/tcp          # LDAP over SSL
kerberos-sec    750/udp          # For compatibility with older "750" clients
kerberos-sec    750/tcp          # For compatibility with older "750" clients
nfsd            2049/udp
nfsd            2049/tcp
nrv             2050/tcp         # NetApp Remote Volume protocol, used in 
                                 # FlexCache and Restore-On-Demand.
 
iscsi-target    3260/tcp
 
nlockmgr        4045/tcp         # NLM
nlockmgr        4045/udp
mountd          4046/tcp         # NFS mountd protocol
mountd          4046/udp
status          4047/tcp
status          4047/udp
pcnfsd          4048/tcp         # PCNFS protocol
pcnfsd          4048/udp
rquotad         4049/udp
 
ndmp           10000/tcp
sm-ics         10565/tcp         # Snapmirror Multipath 
snapmirror     10566/tcp         
sm-sync-block  10567/tcp         # Snapmirror Sync Block Data
sm-sync-trans  10568/tcp         # Snapmirror Sync Transaction Data
sm-sync-ctrl   10569/tcp         # Snapmirror Sync Control Data
nbu-nearstore  10571/tcp         # NetBackup - Nearstore
sm-ics-test    10670/tcp         # INTERNAL USE: Snapmirror Multipath Test
ndmp-local     32243/tcp         # Internal connection inside NetApp box

There are probably a million and one individual pieces of software and websites you can use to generate a randomized password string. But the truth of the matter is that, if you have a UNIX machine, you don’t need them at all! Here’s how to generate a randomized password using widely available UNIX commands.

Random Data

UNIX is really, really good at generating random output. In fact, there is a device dedicated specifically to this cause. Meet /dev/random. We will be using this device as the source of our random password.

What about ASCII?

/dev/random provides us with some *really* random output. If you were to use a section of this random output in its raw form you would likely run into characters that are hard if not impossible to enter with your keyboard. To address this we will use uuencode to convert the raw output into a more human readable base64 version.

Putting it all together

Using dd we can take a small slice of randomness and pipe it into uuencode. The second to last line will be our randomized password.

Note: you may need to install the ‘sharutils’ package onto your system if uuencode isn’t installed by default.

$ dd if=/dev/random bs=1 count=12 | uuencode -m -
begin-base64 644 -
12+0 records in
12+0 records out
12 bytes transferred in 0.000165 secs (72734 bytes/sec)
KJ1yeC4MtSg5QQCY
====

“dd if=/dev/random bs=1 count=12 ” outputs 12 (count=12) bytes (bs=1) of random data (if=/dev/random).

“| uuencode -m -” This reads the input from the previous command (pipe and trailing -) and encodes it into base64 (-m)

And there you have it, your shiny new random password!

If you’re like me then you enjoy time away from the desk. For IT professionals, however, it is not unusual to be interrupted during your personal time with a question or problem from a panicking co-worker or user. It used to be the case that you’d have to drop what you were doing and run to a computer to look into an issue but now that smart phones (iPhones specifically) are so widely available it is easy to troubleshoot a problem remotely from your hand held device. That is, if you have the right apps installed!

Here are the 5 apps that I rely on daily as an IT pro.

Network Utility – IP Troubleshooting Utility

Stuck in an area away from your computer? But still need to check your website or server status? With Network Utility you can check your website or server status from anywhere that you have internet or cell phone reception.

Features:

* Ping (ICMP Echo)
* TCP/IP Port Scan
* GeoIP lookup
* Geotargeting with Google Maps
* Whois Query
* IP Address Information

Screenshots:

[nggallery id=5]

iSource – Source Viewer and DNS Swiss Army Knife

iSource Browser is a source-aware web browser for the iPhone. It is a fully functional web browser with the following additional features.

* HTML source
* WHOIS lookup
* DIG lookup
* HOST lookup
* Emailing of debug info
* Transparent debug console

Screenshots:

[nggallery id=4]

Domain Scout – Domain Availability

Domain scout is a handy utility to perform domain name availability queries quickly from your iPhone.

Features:

* Supports all domains, including global country-codes.
* Customizable top-level domain buttons, to save typing.
* Smart-parsing of top WHOIS formats for convenient viewing.
* Searches are always private & safe from domain front-running.

Screenshots:

[nggallery id=1]

IRC 999 – IRC Client

IRC is an excellent way to get another set of eyes on the problem you’re experiencing. IRC999 provides a fully functional IRC client in your pocket for free. It was a little bit unintuitive to get set up initially, but once up and running it works great!

Screenshots:

[nggallery id=2]

iRdesktop – Remote Desktop Client

iRdesktop is a free Remote Desktop Client for Windows Terminal Services (Remote Desktop Services), capable of natively using the Remote Desktop Protocol (RDP) in order to view and control your Windows Desktop using your iPhone and iPod Touch.

Screenshots:

[nggallery id=3]

Now you are probably wondering where the SSH client is. Unfortunately I haven’t come across a free SSH client for the iPhone. However there are a number of paid clients that you can read more about here.

I hope you find these apps as useful as I do!

Time and time again I run into an instance where I have a file on host 1 and a file on host 2 but host 1 can’t connect directly to host 2. Typically this requires me to copy the file locally to my desktop, then copy it again to the destination host. Thanks to the fact that ssh can tunnel standard input, however, there is a simple way to effectively scp directly from remote host to remote host using your machine as an intermediary. Here’s how.

SCP files using tar and ssh pipes

root@desktop ~ $ ssh host1 'tar -c ./foo' | ssh host2 'tar -x'

As you can see, we are simply redirecting the output of ‘tar -c ./foo’ on host1 to ‘tar -x’ on host2 through ssh. If you want to copy the file to a location other that your home directory on the remote server you can use something similar to the following.

root@desktop ~ $ ssh host1 'tar -c ./foo' | ssh host2 'cd /tmp; tar -x'

All we need to do is execute a cd command prior to our tar command to change the target of the copy.

I hope this helps! If you have a different way to do this leave a commend, I would love to hear it!