Chrooting bind

In DMZ it is often desirable to run dual dns servers.    This allows internal clients to have a local view of a domain (mydomain.com for example), while external (Internet) clients have a different view, being served from a different name server daemon/zone file.

All DMZ DNZ servers should be chrooted for security reasons.  It's a just good security practice  to run DNS chrooted, and with minimal priviliges.

The internal DNS server  daemon  listens on the internal network interface.  It has whatever zone files that it needs to provide an intranet's view of DNS space.  For internal DNS queries that don't refer to a local host, it forwards the request to the external DNS daemon.

The external server daemon listens on the external network interface and the loopback interface.  It handles dns queries from external clients, as well as handling the forwarded  requests from the internal named daemon.

From Chroot'ing BIND

This process has three steps: create a general chroot jail, install BIND into the jail, start and test the chroot'ed BIND.

Set up a general chroot environment

BIND is now up and running, but we want to tighten security further by forcing it to run in a chroot environment (also called a jail or padded cell: Basically, restrict the files visible to BIND to a subdirectory within the file system). See also footnote 2 for a discussion of chroot environments.

We will now walk through the steps for setting up the chroot environment, copying over the BIND files, starting BIND and troubleshooting. These steps chroot the entire BIND program, not just using BIND's "-t" feature (see Note 1).

The following steps assume use of the C-Shell. We start by setting a variable for the chroot environment (jail) location, and setting umask so that all files copied can be read by both groups and world. These commands are designed to be copied and pasted.

1. Set source and destination directories

csh
set jail='/home/dns';
umask 022;

2. Set up empty directories and links:

mkdir $jail;
cd $jail;
mkdir -p {dev,opt,usr,var,etc};
mkdir -p var/{run,log,named} usr/{local,lib};
mkdir -p usr/share/lib/zoneinfo;

3. Setup /etc

cp /etc/{syslog.conf,netconfig,nsswitch.conf,resolv.conf,TIMEZONE} $jail/etc

4. Create a user and group account within chroot and for the whole system. BIND will run under this account.

echo "named:x:20000:20000:BIND DNS daemon:/tmp:/bin/false" >> /etc/passwd
echo "named:x:20000:20000:BIND DNS daemon:/tmp:/bin/false" > $jail/etc/passwd

echo "named:NP:6445::::::"  >> /etc/shadow
echo "named:NP:6445::::::"  > $jail/etc/shadow

echo "named::20000:" >> /etc/group
echo "named::20000:" > $jail/etc/group

5. Set up libraries:

Use ldd to see what shared object libraries named and named-xfer rely on:

ldd /usr/local/sbin/named /usr/local/sbin/named-xfer

Copy the files listed by ldd, for example for Solaris 2.6/7:

cp -p /usr/lib/libnsl.so.1 \
/usr/lib/libsocket.so.1 /usr/lib/libc.so.1 \
/usr/lib/libdl.so.1 /usr/lib/libmp.so.2 $jail/usr/lib

On Solaris 2.5:

cp -p /usr/lib/libnsl.so.1\
/usr/lib/libsocket.so.1 /usr/lib/libc.so.1\
/usr/lib/libdl.so.1 /usr/lib/libmp.so.1 /usr/lib/libw.so.1\
/usr/lib/libintl.so.1 $jail/usr/lib

Experience has shown the following are also needed for Solaris 2.5/6/7:

cp /usr/lib/ld.so.1 /usr/lib/nss_files.so.1 $jail/usr/lib

("Experience" means that first attempts didn't work, but by running BIND with truss, one could see what libraries were being sought after.)

6. Copy over Timezone files (I use MET, here in Europe):

mkdir -p $jail/usr/share/lib/zoneinfo;
cp -p /usr/share/lib/zoneinfo/MET $jail/usr/share/lib/zoneinfo/MET

7. Set up devices for communication, console, syslog, etc.

cd $jail/dev
mknod tcp c 11 42
mknod udp c 11 41
mknod log c 21 5
mknod null c 13 2
mknod zero c 13 12
chgrp sys null zero
chmod 666 null
mknod conslog c 21 0
mknod syscon c 0 0
chmod 620 syscon
chgrp tty syscon
chgrp sys conslog

Copying BIND to the Jail

We assume bind was already in /usr/local, so copy the BIND files over from there:

cd $jail;
mkdir -p usr/local/{bin,lib,sbin,bind,etc}
cd $jail/usr/local/sbin;
(cd /usr/local/sbin; tar cf - dnskeygen named* irpd ndc ) |tar xvf -
cd $jail/usr/local/bin;
(cd /usr/local/bin; tar cf - dnsquery dig host nslookup nsupdate) |tar xvf -
cd $jail/usr/local;
cp /usr/local/etc/named.conf etc;
(cd /usr/local; tar cf - bind) |tar xvf -

Your DNS data can be located in several directories; here we present two examples. The location is specified in named.conf.

1. Data in /etc/named/

mkdir -p $jail/etc/named;  cd $jail/etc/named;
(cd /etc/named; tar cf - * ) | tar xvf -

2. or DNS data in /var/named (my preference)

cd $jail/var/named;
(cd /var/named; tar cf - * ) | tar xvf -

Next, set permissions on files, so that root owns files and named can read all files and write some files. And, disable any SUID/SGID files.
The PID file is put in /var/run and not /usr/local, because we don't want the named user to be able to write to /usr/local/etc (and hence named.conf). The location of the PID file is specified in named.conf.

cd $jail
chmod -R g-w var;
chmod -R a-w opt usr
chmod g+w var/run var/log
chgrp named var/log var/run;
touch var/log/all.log var/run/named.pid;
/usr/ucb/chown named.named
var/log/all.log var/run/named.pid;
chgrp named $jail/usr/local/etc;
/usr/ucb/chown root.named $jail/usr/local/etc/named.conf;
find . -type f -exec chmod ug-s {} \;

See footnote ⁸ for an example of an "ls -alR" on a production DNS primary.

Edit DNS config file: if the PID or data location has changed from your original installation, then $jail/usr/local/etc/named.conf needs to be adapted (see also the section BIND Configuration Notes).

NEWS CONTENTS

• 20110620 : frl1nuX Chrooting Bind under Debian ( frl1nuX Chrooting Bind under Debian, Jun 20, 2011 )
• 20110620 : Dual chrooted BIND/DNS servers ( )

Old News ;-)

[Jun 20, 2011] frl1nuX Chrooting Bind under Debian

29 July 2010 | frl1nuX

I needed to do this quickly so found this nice document than explains it all. Applied to latest Squeeze and works accordingly, here is the quick and dirty guide for the impatient:

#install
apt-get install bind9 bind9-doc dnsutils
/etc/init.d/bind9 stop
#setup of chroot
mkdir -p /var/chroot/bind9/{etc,dev,var/cache/bind,var/run/bind/run}
chown -R bind:bind /var/chroot/bind9/var/*
mknod /var/chroot/bind9/dev/null c 1 3
mknod /var/chroot/bind9/dev/random c 1 8
chmod 666 /var/chroot/bind9/dev/{null,random}
#move config
mv /etc/bind /var/chroot/bind9/etc
ln -s /var/chroot/bind9/etc/bind /etc/bind
#modify syslog config
echo "$AddUnixListenSocket /var/chroot/bind9/dev/log" >> /etc/rsyslog.d/bind-chroot.conf
#setup bind to start chroot
vi /etc/default/bind9
# modify this line: OPTIONS="-u bind -t /var/chroot/bind9"
/etc/init.d/rsyslog restart
ls -al /var/chroot/bind9/dev/log
/etc/init.d/bind9 start

Total time, less than writing this entry :)

Dual chrooted BIND/DNS servers

Dave Lugo [email protected]
version 1.03 updated March 5, 2000

---

On a firewall system it may be desireable to run dual dns servers. This allows internal clients to have a local view of a domain (mydomain.com for example), while external (Internet) clients have a different view, being served from a different name server daemon/zone file.

The servers are chrooted for security reasons. It's a good practice on a firewall to run chrootable services chrooted, and with minimal priviliges.

The internal server daemon listens on the internal network interface. It has whatever zone files that it needs to provide an intranet's local dns needs. For internal dns queries that don't refer to a local host, it forwards the request to the external named daemon.

The external server daemon listens on the external network interface and the loopback interface. It handles dns queries from external clients, as well as handling the forwarded requests from the internal named daemon.

Please note that these instructions are for a Redhat 6.0 install. Minimal tweaking may be needed for other Linux distributions which is not covered here.

---

Download what you need

What you'll need to grab to do this:

The latest production source for BIND from http://www.isc.org/

For getting syslogged data out of the chroot tree, you have 2 choices:

• If your syslogd supports the "-a <socket>" option , you can use that. A quick look at a few Redhat systems I have leads me to believe that you should be fine as long as your version of Redhat is at least 5.1. Check the man page or do a "syslogd -v " and check the output. If it is 1.3-3 or higher you should be ok.
  
• If you can't or don't want to use the syslogd option, you can use holelogd. It is part of the utils-1.0 package at http://www.obtuse.com/. This document covers both methods.

---

Building what you need and creating the chroot area

1. First, if you're using holelogd, extract and build the utils-1.0 package. You may see some warning messages when you compile the package, but as long as holelogd itself compiles ok, we're happy. Don't do a make install, as we'll be copying the newly-produced holelogd executable into the chrooted tree later.

   If you're planning on using syslogd , this would be a good time to look at the man page for syslogd, because in a few minutes you'll need to edit your /etc/rc.d/init.d/syslog script.
   

2. Next, extract and build BIND. If you do a "make install" after building you _may_ want to go back and delete the newly-installed named and named-xfer daemons, as we'll be installing those in the chrooted tree.
   
3. Now we need to create the directory tree, for this example we'll set up everything under /usr/local/bind:

   mkdir /usr/local/bind

   cd /usr/local/bind

   mkdir dbfiles_external

   mkdir dbfiles_internal

   mkdir dev

   mkdir etc

   mkdir lib

   mkdir sbin

4. The dev directory will need a null device file. I originally didn't bother with this, but for some reason zone-xfers would fail if this was missing.

   mknod -m 666 /usr/local/bind/dev/null c 1 3

5. The etc directory will need a few things: passwd and group files with only one entry each - the named user and named group. You should make sure the UID and GID you use are unique. Don't forget to add the chroot named user/group to your non-chrooted /etc/passwd and /etc/group, so that an "ls -l" in the chroot area will show name and group instead of UID/GID. You'll also need copies of /etc/ld.so.cache and /etc/localtime. At this point you should also chown the dbfiles_* dirs.

   cd /usr/local/bind/etc

   echo "named::22" > group

   echo "named:x:22:22:named:/:" > passwd

   echo "named::22" >> /etc/group

   echo "named:x:22:22:named:/:" >> /etc/passwd

   cp /etc/ld.so.cache .

   cp /etc/localtime .

   chown named.named ../dbfiles_*

6. The lib directory will need libc and a few other things. The list here is what works for me under RedHat 6.0, your mileage may vary. You *can* use strace to assist in debugging, see troubleshooting (at the end of this document).

   cd /usr/local/bind/lib

   cp /lib/ld-2.1.1.so .

   ln -s ld-2.1.1.so ld-linux.so.1.9.5

   cp /lib/libc-2.1.1.so .

   ln -s libc-2.1.1.so libc.so.6

   cp /lib/libnsl-2.1.1.so .

   ln -s libnsl-2.1.1.so libnsl.so.1

   cp /lib/libnss_compat-2.1.1.so .

   ln -s libnss_compat-2.1.1.so libnss_compat.so.2

   cp /lib/libnss_files-2.1.1.so .

   ln -s libnss_files-2.1.1.so libnss_files.so.2

7. We'll need to copy over the holelogd (if you're using it instead of passing the "-a <socket>" option to syslogd), named, and named-xfer executables. Depending on where you compiled them you may need to adjust the cp commands. Copying holelogd to a different name (as below) makes things easier if you run multiple holelogd instances (as you might if you chroot other things).You can also strip the executables to save space:

   cd /usr/local/bind/sbin

   cp /usr/src/bind-8.2.2p5/src/bin/named/named .

   cp /usr/src/bind-8.2.2p5/src/bin/named-xfer/named-xfer .

   cp /usr/src/utils-1.0/holelogd holelogd.named    (or not, if using syslogd)

   strip named named-xfer holelogd.named

8. We'll need a named.conf in each of the dbfiles directories. The domain name we use (on both internal and external servers) will be identical, but because we run two named daemons, the external named can have different data for the same domain.

   We also lock things down a bit, using the allow-query and allow-transfer statements available as part of BIND.

   Disclaimer: This document is not a primer on BIND. You should buy the book, it's worth it.

   Disclaimer#2: The example files here have bogus domain name and address values. You will need to provide correct ones.

   Our domain name will be somedomain.com
   Our internal IP address is 192.168.1.1
   Our external IP address is 172.16.10.1

   These conf files can also be downloaded: named.conf.internal named.conf.external
   

   #======================================================
   # named.conf for dbfiles_internal directory.
   #
   # NOTE: Comments in this file begin with a # symbol.
   #
   # NOTE: Remember we're chrooted.  Don't break the paths
   #       below by forgetting that.
   #======================================================
   options {
           directory "/dbfiles_internal";
           pid-file "/dbfiles_internal/internal.pid";
           named-xfer "/sbin/named-xfer";
           #
           # specify the internal IP address of this box
           listen-on { 192.168.1.1; };
           #
           # specify the external IP address of this box
           forwarders { 172.16.10.1; };
           #
           # only allow queries from this source.
           allow-query { 192.168.1/24; };
   };
    
   controls{
           unix "/dbfiles_internal/ndc_internal"
           perm 0600
           owner 0
           group 0;
   };
   
   zone "somedomain.com" in {
           type master;
           file "db.somedomain.com"; 
   };
   
   zone "1.168.192.in-addr.arpa" in {
           type master;
           file "db.192.168.1"; 
   };
   
   zone "0.0.127.in-addr.arpa" in {
           type master;
           file "db.127.0.0"; 
   };
   
   zone "." in {
           type hint;
           file "db.cache"; 
   };

   
   

   #======================================================
   # named.conf for dbfiles_external directory.  
   #
   # NOTE: Comments in this file begin with a # symbol.
   #
   # NOTE: Remember we're chrooted.  Don't break the paths
   #       below by forgetting that. 
   #======================================================
   options {
           directory "/dbfiles_external";
           pid-file "/dbfiles_external/external.pid";
           named-xfer "/sbin/named-xfer";
           #
           # depending on how/if you packet filter, you may 
           # want this. AFAIK, it doesn't hurt.
           query-source address * port 53;
           #
           # global options set to only allow queries from
           # us.  We explicitly allow our served zones to be 
           # queried on a per-zone basis later in this file.
           allow-query { 192.168.1.0/24; 127.0.0.1; 172.16.10.1; };
           #
           # specify the external IP and loopback addresses here.
           listen-on { 172.16.10.1; 127.0.0.1; };
   };
    
   controls{
           unix "/dbfiles_external/ndc_external"
           perm 0600
           owner 0
           group 0;
   };
    
   zone "somedomain.com" in {
           type master;
           file "db.somedomain.com";
           allow-query { any; };
           allow-transfer { 172.16.12.10; 10.0.0.1; };
   };
    
   zone "10.16.172.in-addr.arpa" in {
           type master;
           allow-query { any; };
           file "db.172.16.10";
           allow-transfer { 172.16.12.10; 10.0.0.1; };
   };
    
   zone "0.0.127.in-addr.arpa" in {
           type master;
           allow-query { any; };
           file "db.127.0.0";
   };
    
   zone "." in {
           type hint;
           file "db.cache";
   };

   
   
9. Once you've created all the zone files in your dbfiles_internal and dbfiles_external directories, you should end up with something like this when you do an ls (adjust zonefile names per your network):

   ls -lR /usr/local/bind/dbfiles_*
   
   /usr/local/bind/dbfiles_external:
   total 18
   -rw-r--r--   1 root     root         678 Nov 14 22:28 db.127.0.0
   -rw-r--r--   1 root     root         690 Nov 14 22:29 db.172.16.10
   -rw-r--r--   1 root     root        2769 Aug  1 12:55 db.cache
   -rw-r--r--   1 root     root        1508 Nov 14 22:46 db.somedomain.com
   -rw-r--r--   1 root     root        1425 Nov 19 22:29 named.conf

   /usr/local/bind/dbfiles_internal:
   total 18
   -rw-r--r--   1 root     root         669 Nov 14 22:30 db.127.0.0
   -rw-r--r--   1 root     root         800 Nov 14 22:30 db.192.168.1
   -rw-r--r--   1 root     root        2769 Aug  1 12:54 db.cache
   -rw-r--r--   1 root     root        1062 Nov 14 22:31 db.somedomain.com
   -rw-r--r--   1 root     root        1004 Nov 19 22:38 named.conf

10. Modify/create an /etc/rc.d/init.d/dns startup script. One is provided below that works on a Redhat 6.0 system. You'll need to set up symlinks from the rc.* directories. See the man page for chkconfig (for Redhat systems). Make sure the script is executable once you've copied it to the init.d directory.

    Don't forget to disable your old named startup script. Read the man page for chkconfig, or look at the symlinks in the /etc/rc.* dirs and rename or remove the ones that point to the old script. On a Redhat 6.0 system, the old script is /etc/rc.d/init.d/named

    You can also download this new script here

    #!/bin/sh
    #
    # dns          Start/Stop the internal and external name daemons
    #
    # description: dns is a script for starting/stopping/etc DNS servers
    #              version 1.02 
    # chkconfig: 345 14 58
    # processname: named
     
    # Source function library.
    . /etc/rc.d/init.d/functions
     
    # See how we were called.
    case "$1" in
      start)
            echo -n "Starting DNS services: "
            # 
            # uncomment the following line if you're using holelogd for logging.
            #daemon /usr/local/bind/sbin/holelogd.named /usr/local/bind/dev/log
            daemon chroot /usr/local/bind /sbin/named -b /dbfiles_internal/named.conf  -u named -g named
            daemon chroot /usr/local/bind /sbin/named -b /dbfiles_external/named.conf  -u named -g named
            echo
            ;;
      stop)
            echo -n "Stopping DNS services: "
            killall named
            # 
            # uncomment the following line if you're using holelogd for logging.
            #killproc holelogd.named
            echo
            ;;
      status)
            status named
            # 
            # uncomment the following line if you're using holelogd for logging.
            #status holelogd.named
            ;;
      restart)
            /etc/rc.d/init.d/dns stop
            /etc/rc.d/init.d/dns start
            ;;
      reload-ext)
            ndc -c /usr/local/bind/dbfiles_external/ndc_external reload
            ;;
      reload-int)
            ndc -c /usr/local/bind/dbfiles_internal/ndc_internal reload
            ;;
      reconfig-ext)
            ndc -c /usr/local/bind/dbfiles_external/ndc_external reconfig
            ;;
      reconfig-int)
            ndc -c /usr/local/bind/dbfiles_internal/ndc_internal reconfig
            ;;
      *)
            echo "Usage: dns {start|stop|status|restart|reload-ext|reload-int|reconfig-ext|reconfig-int}"
            exit 1
    esac
    
    exit 0

11. If you decided to use syslogd, you'll need to edit the /etc/rc.d/init.d/syslog script and change one line. Note that these are the changes that I did on my system, your system (depending on which distribution and other factors) may be different.

    Old line:        daemon syslogd -m 0
    
    New line:        daemon syslogd -a /usr/local/bind/dev/log -m 0

    Don't forget to restart syslogging with the new options:

    /etc/rc.d/init.d/syslog restart

12. Assuming you've done everything correctly, try starting the dns servers.

    /etc/rc.d/init.d/dns start

    The named daemons should create pid and ndc files (per the named.conf files) in each of your dbfiles directories. You should also notice a new file called "log" in the chrooted dev directory that holelogd/syslogd uses to pipe log data to /var/log/messages.
    
13. You may also want to adjust your /etc/resolv.conf file so that clients on the same system use the internal server for dns resolution. The "forwarders" line in the internal daemons's named.conf file will handle queries for non-local data.

    search somedomain.com
    nameserver 192.168.1.1

---

Troubleshooting

If the daemon doesn't start correctly, you can use strace as a diagnostic aid. Change the daemon lines in the dns script so they are similar to the following (change internal to external as needed), and you'll have strace files in /tmp to help you figure out what's missing.

 daemon strace -o /tmp/dns.strace -f -ff chroot /usr/local/bind /sbin/named \
 -b /dbfiles_internal/named.conf -u named -g named

You can of course have named produce debug output. RTFM

---

Comments and/or Suggestions?

Please send them to me at [email protected] Warning to spammers: If you use this address to send me unsolicited crap, you consent to my LARTing you.

Recommended Links

Softpanorama Recommended

Top articles

Sites

Building and configuring BIND 9 in a chroot jail

freshmeat.net Project details for ctk-adm-dns-chroot ctk-adm-dns-chroot creates the minimum file structure needed to run bind as a chrooted unprivileged user.

howto_bind_chroot_debian

Chroot-BIND HOWTO

chrooting BIND on FreeBSD

Adam Shostack's Homepage -- older staff about chroot.

How to set up one machine with two BIND servers, to implement a split internal/external view of DNS, using the chroot environment. Targeted to Redhat Linux 6.0. Note that some people regard chroot environments as not especially secure. 05-Mar-2000

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 29, 2020