Softpanorama

May the source be with you, but remember the KISS principle ;-)
Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

Solaris DNS Tutorial, part 2/3

Prev Index Next

Configuring the Solaris DNS Server

The named daemon under Solaris 9 is /usr/sbin/in.named and is started upon system boot by the init scripts if the /etc/named.conf file is detected.

The init script that launch named is /etc/init.d/inetsvc. It simply checks if /etc/named.conf exists. If yes, then it start BIND by executing /usr/sbin/in.named

Like many other Solaris init scripts /etc/init.d/inetsvc accept parameters: start and stop. Actually checking for the existence of configuration file is "Solaris way" of starting many network daemons. You can also disable services "forever" by renaming link to this script /etc/rc2.d/S72inetsvc which links to /etc/init.d/inetsvc

To start or restart named you can call the /etc/init.d/inetsvc script as root with the an argument "start" (you need to make sure we start fresh and kill existing in.named process if it is running; you can also make first a similar call the "stopt" switch.

/etc/init.d/inetsvc stop; /etc/init.d/inetsvc start 
Setting netmask of hme0 to  w.x.y.z 
starting internet domain name server.

Note that you could also just run /usr/sbin/in.named at the command line as well. This is fine, but later on when we upgrade BIND to a later version, we'll need to specify options on the command line and doing it this way would be tedious. Instead it's better to modify the /etc/init.d/inetsvc script and let it pass all the nessesary parameterss.

You'll notice when you start things up, a line should hopefully appear as above, reading "starting internet domain name server." This means that your configuration files are in place and now, hopefully, named is running and ready to answer queries. You can verify this and also see if any errors came up when named started by looking at your /var/adm/messages log file. You should at least see something that looks like this:

Mar  2 10:53:13 hostname named[20937]: starting.  in.named BIND
8.1.2 Tue Nov 10 1 8:16:24 PST 1998
Mar  2 10:53:13 hostname named[20938]: Ready to answer queries.

If that's the case, then you're aces and ready to move on. Always check if there are any errors in formatting or syntax in your configuration files /var/adm/messages log file. For example:

tail -20 /var/adm/messages

The messages are usually pretty self-explanatory, so if you come across any you should be able to figure out what to do.

Typical mistakes:

If you're just updating DNS database and named is already running, you could just send the named process a "HUP" signal, which would force named to re-read your configuration. This can be accomplished by running this at the command line, as root:

kill -HUP `cat /var/named/named.pid`

Gathering Information

When you configure a DNS server, supply the server with the following types of information:

  1. The names and addresses of root servers (roots hint).
  2. The information required to resolve all domains for which the server is authoritative. This information consists of name-to-address translations.
  3. The information needed to resolve all reverse domains for which the server is authoritative. This information consists of address-to-name translations.
  4. The names and addresses of servers for all domains that are one level below the domains being served by this server. This information is sometimes referred to as parenting or delegating.

Editing the BIND Configuration File

BIND version 8.x.x and later versions use a configuration file /etc/named.conf. It contains several statements that:

The in.named process reads the /etc/named.conf file when the process is started by the server’s startup script, /etc/rc2.d/S72inetsvc. The configuration file directs the in.named process either to other servers or to local data files for a specified domain.

The /etc/named.conf file contains statements and can contain comments. Statements end with a semicolon (;), they can contain a block of statements enclosed within curly braces ({}), and each statement in the block is terminated with a semicolon (;). Comments can start with /*and end with */, can follow either #or //, and can extend to the end of the line.

#
# Prolog
#

options {
directory "/var/named"; # where you directory with DNS database is located
};

#
# How to find root server
#
zone "." in {
type hint;
file "named.root";
};

# end of Prolog

#
# our own zone
#
zone "net.myfirm.com" in {
type master;
file "net.myfirm.com.db";
};

#
# Reverse translations (hopefully generated automatically by special script)
#

zone "144.144.10.in-addr.arpa" in {
type master;
file "144.144.10.in-addr.arpa.db";
};

#
# Epilog.
#

zone "0.0.127.in-addr.arpa" in {
type master;
file "0.0.127.in-addr.arpa.db";
};



Statement types

  1. acl Defines a named IP address match list used for access control. The address match list designates one or more IP addresses or IP prefixes. The named IP address match list must be defined by an acl statement before it can be used elsewhere. No forward references are allowed.
  2. options Controls global server configuration options, and sets default values for other statements.
  3. zone Defines a zone. It selectively applies options on a per-zone basis, rather than to all zones.

Editing the named.root File


The /var/named/named.root file specifies name-to-address mappings for the root servers.

The information in this file is described as “hints” to the in.named process because the name daemon attempts to contact one of the root servers listed until one of the servers responds. The responding root server returns a list of root servers. The name daemon uses this list that is returned from the root server and does not use the servers that are specified in the hintsfile again until the TTL value expires on the cached root-server information.

Accordingly, it is not imperative that this file be precisely up-to-date, but it should be checked every few months because root servers change from time to time.

The following is a modified (the INentries for servers D through L are not present in the file retrieved from internic.net) excerpt taken from a named.root file available at the ftp://ftp.rs.internic.net/domain/named.root Web site.

; formerly NS.INTERNIC.NET

;
. 3600000 IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
;
; formerly NS1.ISI.EDU
;
. 3600000 IN NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107
;
; formerly C.PSI.NET
;
. 3600000 IN NS C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12
< Part of file truncated>
; housed in Japan, operated by WIDE
;
. 3600000 IN NS M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33
; End of File

where in the first record:

Editing the Forward-Domain File

The forward-domain file contains the mappings of host names to IP addresses for all systems in the domain that are being served by this name server. In addition, this file must specify an SOA record and NS records for all name servers for this domain.

; Information for the "forward" domain one.edu.


; Time to live 8 hours

$TTL 8h

@ IN SOA utlra.rockaway.myfirm.com. carrw.myfirm.com (
20060804; Version number: US SHOULD BE THE DATE. IF YOU FORGET TO UPDATE IT SLAVE WILL NEVER GET UPDATE.
43200; Refresh timer - 12 hours
3600; Retry timer - 1 hour
604800; Expire timer - 1 week
3600; Negative caching info. kept 1hr
)

; Define name servers for this domain.
IN NS utlra.rockaway.myfirm.com. ; primary
IN NS labdns.rockaway.myfirm.com. ; secondary

; Define name to address mappings for this domain.

IN A 192.168.1.1
rockaway-rh_if-1 IN A 10.194.144.2
# full name is rockaway-rh_if-1.net.myfirm.com
rock_8600_main IN A 10.194.144.1

; CNAME aliases.

rock_secondary IN CNAME rock_8600_main

; Loopback domain definition.

localhost IN A 127.0.0.1

$TTL 86400
@ IN SOA sys-04.lab7.sunedu.com. root.sys-04.lab7.sunedu.com ( 0001 10800 3600 932000 86400 )
IN NS sys-04.lab7.sunedu.com.
sys-01 IN A 192.168.201.21
sys-02 IN A 192.168.201.22
sys-03 IN A 192.168.201.24
sys-04 IN A 192.168.201.25


The $TTLdirective sets the default time to live for the zone’s information to eight hours.

The SOA record is mandatory and has the following items:

  1. An at sign @) in the domain field – This is a shortcut for the domain that is being served (one.edu. in this case). The actual value for the @ comes from the second field of the appropriate record in the named.conf file. The @ also defines the default origin that determines the domain appended to any partially qualified domain name in the configuration file’s resource records.
  2. Data field argument 1 (sys11.one.edu.)– This is the name of the primary master server for this domain in FQDN format.
  3. Data field argument 2 (root.sys11.one.edu)– This is an email address, in the format of DNS_admin_name.domain_name, that you can use to report problems with the domain. The administrator is usually the root user, as shown in this example. Note that the @is replaced with a dot in the SOA record because the @has special meaning in this file.
  4. Data field argument 3 – This is the version (serial) number that the secondary slave servers use to determine if they need to perform a zone transfer to get a fresh copy of zone data. Any time you make changes to this file, remember to update this number in such a way that it gets larger. It is always safe to start at 1 and add 1 with each change, or to use today’s date.
  5. Data field argument 4 – The refresh timer is the time interval, in seconds, after which the secondary master servers should check to determine if the serial number has changed, and, if it has, a zone transfer needs to occur.
  6. Data field argument 5 – The retry timer is the time interval, in seconds, after which the secondary master servers check back if a normal refresh failed. This timer is usually set to a smaller value than the refresh timer.
  7. Data field argument 6 – The expire timer is the time interval in seconds after which, if a secondary server cannot contact the primary server or another secondary server, the entire zone data should be discarded. This prevents the secondary servers that have lost contact with the rest of the name servers from continuing to give out potentially stale information.
  8. Data field argument 7 – The negative caching timer is the default value of time that the server keeps negative responses from other authoritative servers. You should define an NS record for all name servers in this domain that you want to be recognized by DNS servers.

Most of the remaining resource records are address records (A-record) for each system in the domain. Most of the host names are not fully qualified. The names that are not fully qualified have the domain name origin (the value of the @ in the SOA record by default) appended to them. This shorthand method can save typing and improve the readability and maintainability of the file.

The CNAME record defines host aliases or nicknames for hosts. The CNAME record in this instance is similar to an entry of 192.168.1.1 sys11 www in the /etc/inet/hosts file.

The localhost entry specifies the loopback address for all hosts.

Editing the Reverse-Domain File

Reverse-domain files, for example, /var/named/one.rzone, contain mappings for address-to-name translation. Address-to-name translation is important and is used by varying utilities, such as Network File System (NFS), web servers, BIND, and sendmail.

The following is an example of a reverse-domain file:

; Information for the "reverse" domain 1.168.192.in-addr.arpa.


@ IN SOA sys11.one.edu. root.sys11.one.edu. (
20011226 ; Version number
43200 ; Refresh timer - 12 hours
3600 ; Retry timer - 1 hour
604800 ; Expire timer - 1 week
3600 ; Negative caching info. kept 1 hr.
)

; Define name servers for this domain.

IN NS sys11.one.edu.; primary
IN NS sys13.one.edu.; secondary

; Define address to name mappings for this domain.

1 IN PTR sys11.one.edu.
2 IN PTR sys12.one.edu.
3 IN PTR sys13.one.edu.

Observe the following about this file:


Editing the Reverse-Loopback Domain File

Reverse-loopback domain files specify the reverse-loopback domain address-to-name translation. The contents are hard-coded with the exception that the server name changes depending on which server the file is installed. This file is required on all DNS servers. Every name server is the master for its own loopback address.

The /var/named/loopback_domain_info file is an example of a reverse-loopback domain file:


; Information for the loopback domain 127.in-addr.arpa.

@ IN SOA sys11.one.edu. root.sys11.one.edu. (
20011226 ; Serial number
43200 ; Refresh timer - 12 hours
3600 ; Retry timer - 1 hour
604800 ; Expire timer - 1 week
3600 ; Negative caching info kept 1 hr.
)


; Define name servers for this domain.

IN NS sys11.one.edu.


; Define appropriate mappings for this domain.


1.0.0 IN PTR localhost.one.edu.


Observe the following about this file:


Configuring Dynamic Updates

Dynamic updates cause a DNS server to automatically be updated with DHCP host information from a DHCP server. This allows nomadic DHCP users to have access to systems and services without manual administration. To configure a server to allow dynamic updates to occur, complete the following steps:

1. Login as root on the DNS primary server, edit the /etc/named.conf file, and add allow-update statements to both
the forward and reverse zones. For example:


zone "one.edu" in {
type master;
file "one.zone";
allow-update { 127.0.0.1; 192.168.1.1; };
};


zone "1.168.192.in-addr.arpa" in {
type master;
file "one.rzone";
allow-update { 127.0.0.1; 192.168.1.1; };


};


2. Restart the in.named process.
pkill -HUP in.named


Configuring Security

Because of the nature of the Internet, DNS can be vulnerable to unauthorized access.

Beginning with BIND version 8.x.x, security features are implemented through the /etc/named.conf configuration file. Two important security considerations are the control of name queries and the control of zone transfers. By default, servers respond to any query or request for a zone transfer. You can modify this behavior by using the allow-query and
allow-transfer keywords.

The allow-query statement enables you to establish an IP address-based access list for queries. You can apply this access list to a specific zone or to all queries that are received by the server. The IP address list determines which systems receive responses from the server.

You can restrict queries to all zones by using the allow-query keyword as an argument to the options statement for the zone.

For example:

options {
allow-query { 192.168.1/24; 192.168.3/24; };
};

In this case, only systems with the IP addresses 192.168.1.xxx and

192.168.3.xxx receive responses from the name server. You can restrict queries for a specific zone by using the allow-query keyword as an argument to the zone statement. For example:


zone "one.edu" in {
type master;
file "one.zone";
allow-query { 192.168.3/24; };
};


In this case, only subnet 192.168.3.0 has access to the resource records for this zone.

In the same manner, the allow-transfer keyword can limit which systems may receive a zone transfer from a name server. You can restrict zone transfers from a name server by using allow-transfer in the options statement. For example:

options {
allow-transfer {192.168.1.3;};
};

The allow-transfer keyword can also be applied to a specific zone, if you want. Another feature that often is associated with restricting queries and transfers is access control lists (ACLs). The list of IP addresses used in the previous examples could be replaced by an ACL.

You can configure ACLs by using the acl keyword to build an ACL list that can be used as an argument to the allow-query and allow-transfer keywords.


For example:

acl "local" { 192.168.1.0/24; 192.168.2.0/24; 192.168.3.0/24;};

zone "one.edu" in {
type master;
allow-query { "local"; };
allow-transfer { "local"; };
};

Configuring Secondary DNS Servers

The contents of the /etc/named.conf file on the secondary DNS server can be less complex than that of the primary server. If a server is to act as both a primary server for some domains and a secondary server for other
domains, the /etc/named.conf file must contain keywords that are appropriate to both servers. The master keyword denotes a primary server for a domain, and the slave keyword denotes a secondary server
for a domain when used as arguments to the type directive.

An example of a /etc/named.conf file for a secondary master server is:


options {

DIRECTORY "/var/named";
};
zone "." in {

type hint;

file "named.root";
};
zone "127.in-addr.arpa" in {
type master;
file "loopback-domain-info";
};


zone "one.edu" in {
type slave;
file "one-backup";
masters {
192.168.1.1;
};
};


zone "1.168.192.in-addr.arpa" in {
type slave;
file "one-rbackup";
masters {
192.168.1.1;
};
};


Observe the following about this file:


Configuring DNS Clients


All DNS clients require the nsswitch.conf and resolv.conf files. DNS servers also function as DNS clients.

The /etc/nsswitch.conf file specifies to the resolver library routines that DNS uses when resolving host names and addresses. Modify the nsswitch.conf file by editing the hosts line and adding the dns keyword. To ensure proper network interface configuration during the boot process, make sure that the files keyword is listed first. The
following example shows a hosts entry configured for DNS:

hosts: files dns

The /etc/resolv.conffile specifies the name servers that the client must use, the client’s domain name, and the search path to use for queries.

;resolv.conf file for DNS clients of the one.edu. domain.

search one.edu two.edu three.edu
nameserver 192.168.1.1 ; Primary Master Server for one
nameserver 192.168.1.2 ; Secondary Master Server for one


Observe that the search keyword specifies domain names to append to queries that were not specified in the FQDN format. The first domain listed following the search keyword designates the client’s domain.

The nameserver keyword specifies the IP address of the DNS servers to query. Do not specify host names. You can use up to three nameserver keywords to increase your chances of finding a responsive server. In general, list the name servers that are nearer to the local network first. The client attempts to use the loopback address if there is no nameserver keyword or if the /etc/resolv.conf file does not exists.

Troubleshooting the DNS Server Using Basic Utilities

Usually, you cannot test every record in your domain files. Test representative samples, and test several servers in other domains to ensure that you have correctly identified the root servers.

Examining the /var/adm/messages File

The in.named process sends messages to the syslog process, which processes messages at various syslog levels and sends messages to the /var/adm/messages file by default. The contents of this file often show where configuration errors were made. For example, the following entry shows that the negative caching timer was not properly set, indicating that pre-BIND version 8.2 is not properly converted.

Dec 26 02:28:06 sys11 named[1404]: [ID 295310 daemon.notice] starting
(/etc/named.conf). in.named BIND 8.2.4 Tue Nov 13 17:10:11 PST 2001
Dec 26 02:28:06 sys11 s81_51-5.9-May 2002
Dec 26 02:28:06 sys11 named[1404]: [ID 295310 daemon.warning] Zone
"one.edu" (file one.zone): No default TTL ($TTL <value>) set, using SOA
minimum instead

The following message informs you might want to edit the SOA record to be more than seven days:

Dec 26 02:28:06 sys11 named[1404]: [ID 295310 daemon.warning] one.zone:
WARNING SOA expire value is less than 7 days (432000)

Syntax errors are pointed out in the following example:


Dec 26 10:38:15 instructor named[564]: [ID 295310 daemon.notice]
starting. in.named BIND 8.2.2-P5 Tue Jun 19 14:55:52 PDT 2001
Dec 26 10:38:15 instructor Beta-5.9-May 2002
Dec 26 10:38:15 instructor named[564]: [ID 295310 daemon.notice]
root.zone:18: Database error near (instructor.thirty.edu.)
Dec 26 10:38:15 instructor named[564]: [ID 295310 daemon.notice]
root.zone:20: Database error near (one.edu.)
Dec 26 10:38:15 instructor named[564]: [ID 295310 daemon.notice]
root.zone:22: Database error near (three.edu.)
Dec 26 10:38:15 instructor named[564]: [ID 295310 daemon.notice]
root.zone:27: Database error near (sys31.three.edu.)
Dec 26 10:38:15 instructor named[564]: [ID 295310 daemon.warning] master
zone "" (IN) rejected due to errors (serial 20011226)

Dec 26 10:38:15 instructor named[565]: [ID 295310 daemon.notice] Ready to
answer queries.

Using the nslookup Utility

Before the Solaris 9, the primary test tool bundled with BIND was the nslookup utility. As of the Solaris 9 OE, the dig utility is also bundled with the Solaris 9 OE. The nslookup utility usually does the following:


A typical debug session might look like the following:

Note – Some output is omitted for clarity.

sys12# nslookup

Default Server: sys11.one.edu
Address: 192.168.1.1
>

The server listed as the default server is usually the first server listed in the /etc/resolv.conf file. You can change this server later by using the nslookup server directive.

The nslookup utility uses a > (greater than) prompt. The name of the server that is being queried is always displayed first (and is omitted from future examples), followed by the query and the reply.

To list the contents of the domain, use the following command:

> ls one.edu
[sys11.one.edu]
$ORIGIN one.edu.
sys12 8H IN A 192.168.1.2
sys13 8H IN A 192.168.1.3
sys11 8H IN A 192.168.1.1
>

Use of $ORIGINvariable resets the current origin, setting it to the value @, included in the beginning SOA record (shorthand notation).

In the preceding example, the name servers and address records that make up the one.edu domain are listed.


> set q=ns
> one.edu.
...
one.edu nameserver = sys11.one.edu
sys11.one.edu internet address = 192.168.1.1
>

The setq=ns subcommand lists the name server and its location (IP address) for the specified domain (one.edu.)

In this next example, all of the name servers for the domain are listed and the reverse-address lookup is tested. Notice that the nslookup utility allows you to enter the IP address in regular forward notation without the trailing in-addr.arpa. domain name.


> set q=ptr
> 192.168.1.1
...
1.1.168.192.in-addr.arpa name = sys11.one.edu
1.168.192.in-addr.arpa nameserver = sys11.one.edu
sys11.one.edu internet address = 192.168.1.1
>

In this example, the DNS server is changed from the sys11.one.edu. server to the sys13.one.edu. server.

> server sys13.one.edu.
Default Server: sys13.one.edu
Address: 192.168.1.3
>

To make sure that DNS is working correctly, complete the following:

If any of your tests have errors or have no response, you must debug the problem that is often an omission from a file, such as a missing IP address or host name entry or a typographic error in a host entry.

Dumping a Snapshot of the DNS Database

The INT signal, when used with the pkill utility, causes the name daemon to take a snapshot of its in-memory cached data and write this information to the /var/named/named_dump.db file in ASCII (resource record) format. If you prefer to use the kill utility, the /etc/named.pid file contains the process identification number (PID) of the in.named process that is currently running.

You can use the INT signal with the pkill utility to debug both authoritative and non-authoritative lookups. For example:

pkill -INT in.named

You can view the resulting file with your text editor and examine it for problems. For example, a missing trailing dot at the end of an FQDN results in the name being stored internally with the domain part of the
name being repeated, that is one.edu.one.edu.

Changing the Debug Level of the Name Daemon

You can use the USR1 signal with the pkill utility to cause the name daemon (in.named) to increase its debug level (disabled by default) by one. For example:

pkill -USR1 in.named

Each successive increase generates more debug output. You can examine the resulting output in the /var/named/named.run file. A discussion of this file is beyond the scope of this lecture and is described in DNS and BIND, by Paul Albitz and Cricket Liu, O’Reilly & Associates.

You can use the USR2 signal with the pkill utility to cause the name daemon to return to debug level 0 in which debugging is turned off.

Forcing the in.named Process to Reread Configuration Files

You can use the HUP signal with the pkill utility to cause the name daemon to reread all of its configuration files. For example:

pkill -HUP in.named

An advantage of using the HUP signal as opposed to restarting the in.namedprocess is that the zone files are reread, but all of the previously cached information is retained.

Modifying the DNS Server With the ndc Utility

Administrators can use the name daemon control program (ndc) to control the operation of a name server. Name servers have always been controlled by administrators sending signals, such as SIGHUP and SIGINT. The ndc utility provides a finer granularity of control, and it can be used both interactively and non-interactively. For example:

1. Start the ndc utility in the interactive mode.

ndc

Type help -or-/h if you need help.

2. Display usage help.


ndc> /h
/h(elp) this text
/e(xit) leave this program
/t(race) toggle tracing (protocol and system events)
/d(ebug) toggle debugging (internal program events)
/q(uiet) toggle quietude (prompts and results)
/s(ilent) toggle silence (suppresses nonfatal errors)

3. Display more usage information.

ndc> help
(builtin) start - start the server
(builtin) restart - stop server if any, start a new one
getpid
status
stop
exec
reload [zone] ...
reconfig [-noexpired] (just sees new/gone zones)
dumpdb
stats [clear]
trace [level]
notrace
querylog
qrylog
help
quit

4. Restart the in.named process.

ndc> restart 
new pid is 1754

5. Display the status information, including the BIND version.


ndc> status
in.named BIND 8.2.4 Tue Nov 13 17:10:11 PST 2001 s81_51-5.9-May 2002
config (/etc/named.conf) last loaded at age: Tue Dec 25 22:14:06 2001
number of zones allocated: 64
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is ON
server is up and running

6. Dump the database by using the following command:

ndc> dumpdb

Database dump initiated. You can also use the pkill -INT in.named command.

7. Exit the utility.

ndc> /e

You can also use the ndc utility from the command line. For example, to dump the database to the /var/named/named_dump.db file, perform the command:

ndc dumpdb 
Database dump initiated.



Etc

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes.   If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner. 

ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.  

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 quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard 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 DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting 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-MonthHow 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


Copyright © 1996-2016 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.

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.

Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info

Disclaimer:

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 author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: October 11, 2015