|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
|
|
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:
Remember to restart named if you made changes to any configuration files and watch the log file output again until it's clean - or at least starts up with the "Ready to answer queries." entry.
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`
When you configure a DNS server, supply the server with the following types of information:
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";
};
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:
; 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:
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.
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:
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:
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
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"; };
};
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:
Note – Secondary servers can also perform zone transfers from other secondary servers.
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.
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.
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.
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.
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.
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.
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.
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.
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
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. 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 to buy a cup of coffee for authors of this site |
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 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 12, 2019
