NIS and LDAP Netgroups

NIS netgroups are groups (sets) of users or machines that you define for your administrative purposes. LDAP also now incorporates this functionality.  A netgroup can be used in most NFS and NIS configuration files instead of a host name or a user name. A netgroup does not create any relationship between users and hosts. It is essentially a simple macro.  When a netgroup is used in a configuration file, it represents either a group of hosts or a group of users but never both. For example, you can create netgroups that do the following:

• Define a set of users who can access a specific machine
• Define a set of NFS client machines to be given some specific file system access
• Define a set of users who are to have administrator privileges on all the machines in a particular NIS domain

Each netgroup is given a netgroup name. Netgroups do not directly set permissions or access rights. Instead, the netgroup names can be used in configuration files in places where a user name or machine name would normally be used.

For example, suppose you created a netgroup of network administrators called netadmins. To grant all members of the netadmins group access to a given machine, you need only add a netadmin entry to that machine's /etc/passwd file. Netgroup names can also be added to the /etc/netgroup file and propagated to the NIS netgroup map. See netgroup(4) for more detailed information on using netgroups.

On a network using NIS, the netgroup input file on the master NIS server is used for generating three maps: netgroup, netgroup.byuser, and netgroup.byhost. The netgroup map contains the basic information in the netgroup input file. The two other NIS maps contain information in a format that speeds lookups of netgroup information, given the machine or user.

Entries in the netgroup input file are in the format: name ID, where name is the name you give to a netgroup, and ID identifies a machine or user who belongs to the netgroup. You can specify as many IDs (members) to a netgroup as you want, separated by commas. For example, to create a netgroup with three members, the netgroup input file entry would be in the format: name ID, ID, ID. The member IDs in a netgroup input file entry are in the following format.

([-|machine], [-|user], [domain])

Where machine is a machine name, user is a user ID, and domain is the machine or user's NIS domain. The domain element is optional and should only be used to identify machines or users in some other NIS domain. The machine and user element of each member's entry are required, but a dash (-) is used to denote a null.

It is important to understand that there is no necessary relationship between the machine and user elements in an entry and such definitions usually should be split into two: one for users and one for servers.

admins (-,john), (-,nick)

Various programs use the netgroup NIS maps for permission checking during login, remote mount, remote login, and remote shell creation. These programs include mountd, login, rlogin, and rsh. The login command consults the netgroup maps for user classifications if it encounters netgroup names in the passwd database. The mountd daemon consults the netgroup maps for machine classifications if it encounters netgroup names in the /etc/dfs/dfstab file. rlogin and rsh In fact, any program that uses the ruserok interface consults the netgroup maps for both machine and user classifications if they encounter netgroup names in the /etc/hosts.equiv or .rhosts files.

If you add a new NIS user or machine to your network, be sure to add them to appropriate netgroups in the netgroup input file. Then use the make and yppush commands to create the netgroup maps and push them to all of your NIS servers. See netgroup(4) for detailed information on using netgroups and netgroup input file syntax.

Netgroups are only available to sites running NIS or NIS+. There is no local files implementation of netgroups. They are used to group machines or users together in order to make certain sysadmin tasks easier.

The man page for negroups contains several example usage of netgroups.  Another source of  example is  Managing NFS and NIS, 2nd Edition by Hal Stern at all

Though netgroup pairs (or triples) group together hostnames, usernames and domainnames, nothing really reads them in that manner. They exist only in NIS maps. The file /etc/netgroup only exists in order to be your 'flat' source file.

For example, the following would be a typical /etc/netgroup file, on a NIS master:

# cat /etc/netgroup

root-users (-,user1), (-,user2), (-,user3)
trusted-machines (machine1,-), (machine2,-), (machine3,-)

Netgroups are limited to 1024 characters in size.

If you need to put together a longer netgroup, you can do so by making a meta-group:

meta-group netgroup1 netgroup2 netgroup1

The following netgroup will not do what you expect:

bogus-group (machine1,user1), (machine2,user2) # not what you might think !!!

You might think this means user1 at machine1 and user2 at machine2, but in actuality, it is a netgroup that defines either  two users (user1 and user2) if used in place were configuration file expects users or two machines (machine1 and machine2) is uses when particular configuration file expects list of hosts.

The following entry would include all of the users in the root-users group in your /etc/passwd  and /etc/shadow files:

# cat /etc/passwd ... +@root-users

# cat /etc/shadow ... +@root-users

On Solaris you must also edit /etc/nsswitch.conf in order to use that +/- syntax:

passwd: compat group: compat

You need to specify passwd: compat group: compat  in  /etc/nsswitch.conf in order to use that +/- syntax on Solaris

Machine netgroups are usually used for defining rules for exporting file systems. The following entry in /etc/exports on a Solaris machine represent a classic usage when you allow machines in the trusted-machines netgroup access to the /export filesystem:

# cat /etc/exports

/export -access=trusted-machines

Remember that you must be running NIS or NIS+ for netgroups to work.  LDAP also now incorporates this functionality. Simply creating a file /etc/netgroup file will do nothing unless NIS, NIS+ or LDAP are implemented.

NEWS CONTENTS

• 20040401 : Linux.com SysAdmin to SysAdmin Netgroups are not just for NIS anymore ( Linux.com SysAdmin to SysAdmin Netgroups are not just for NIS anymore, Apr28, 2004 )
• 20040401 : Configuring and Using NFS Netgroups ( Configuring and Using NFS Netgroups, )
• 20040401 : Netgroup Examples ( )
• 20040401 : Using Netgroups in the /etc/exports File ( )
• 20040401 : Using Netgroups in the /etc/hosts.equiv or $HOME/.rhosts File ( )
• 20040401 : Using Netgroups in the /etc/passwd File ( )
• 20040401 : Using Netgroups in the /etc/group File ( )
• 20040401 : [Chapter 19] 19.4 Suns Network Information Service (NIS) ( [Chapter 19] 19.4 Sun's Network Information Service (NIS), )
• 20040401 : 19.4.4.1 Setting up netgroups ( softpanorama.org, )
• 20040401 : 19.4.4.2 Using netgroups to limit the importing of accounts ( softpanorama.org, )
• 200102 : How netgroups affect security on an NIS network ( How netgroups affect security on an NIS network, )

Old News ;-)

[Apr28, 2004] Linux.com SysAdmin to SysAdmin Netgroups are not just for NIS anymore

Wednesday April 28, 2004 (08:00 AM GMT)

By: Brian Jones

With recent advances in freely available LDAP client utilities, Linux administrators can now take advantage of some of the benefits of network groups without the overhead of maintaining a NIS server. In this article, I'll explain what netgroups are, and how they can help you get finer-grained control over your local system security.

Netgroups came along as part of Sun's Network Information Service (NIS) naming service. The administrator community soon discovered their utility and pressured the developers of the underlying glibc and NSS libraries to support looking up basically anything in nsswitch.conf from any service (NIS, LDAP, files, or otherwise).

Netgroups are not the same as normal POSIX groups. For one thing, netgroups don't have to have anything at all to do with users. You can have netgroups that represent groups of hosts as well. This feature, however, also comes with a slight increase in complexity in terms of how netgroups are defined. With a normal group, you have a record in your NIS group map or /etc/group file that indicates the group name, a password (which is usually not used in many environments), the numeric group ID, and then a comma-delimited list of users that belong to the group. A typical POSIX group entry looks like this:

wheel:x:10:joe,karen,tim,alan

Netgroups, on the other hand, are defined as "triples" in a netgroup NIS map, or in an LDAP directory; three fields, representing a host, user and domain -- in that order. All three are optional. Let's have a look:

trustusr (-,steve,) (-,jonesy,)
trusthost (deathstar,-,) (falcon,-,)

The "trustusr" netgroup consists of two users, steve and jonesy. We know that they are users because the names are in the middle field of the triple. The "trusthost" netgroup consists of two hosts, deathstar and falcon. We know that they're both hosts because their names are in the first field. The last field in a netgroup triple is reserved for a domain name. If you're using NIS, your clients bind to a domain, and this field becomes more meaningful. For users storing the triples in an LDAP directory, you don't bind to a domain, so this field doesn't need to be used.

Let's have a quick look at a couple of areas where netgroups can be put to effective use. Of course, if you're an administrator who is making the slow, painful migration from NIS to LDAP, one clear benefit to using netgroups is not having to reconfigure all of the clients that [are defined in them?], but there are many others.

The TCP Wrappers configuration files

The /etc/hosts.allow and hosts.deny files support a package called TCP Wrappers that helps administrators define a fairly robust security configuration for a given host. TCP Wrappers lets you can monitor and filter incoming requests for several network services. The software essentially intercepts connection attempts, checks the attributes of the connection (source, service, user, etc.) against the configuration files, and allows or denies connections accordingly. TCP Wrappers configuration can get somewhat complex, and is outside the scope of this article. If you need help with it, you can enter the shell command man 5 hosts_access.

Let's look at typical host.allow and hosts.deny files that don't use netgroups and compare them to an equivalent hosts.allow that does. The typical files look something like:

#
# hosts.allow
#

in.cfingerd:ALL
portmap:ALL
ALL:192.168.2.,192.168.3.,.linuxlaboratory.org EXCEPT badhost.linuxlaboratory.org, opus, willy

#
# hosts.deny
#
ALL:ALL

Our hosts.allow file says to allow access to the finger daemon and portmap to anyone. However, there are apparently other daemons running on this machine, and the only hosts allowed to access these other services are (in order):

• Any host in the 192.168.2 or 192.168.3 subnets.
• Any host in the linuxlaboratory.org domain (except for badhost), and
• hosts "opus" and "willy."

That's a lot of typing, with a lot of room for typos, it takes a lot of parsing to read it. This configuration also leaves some room for extra hosts to get by who you had no intention of giving access to. For example, if you add a new host to the linuxlaboratory.org domain, it automatically has access to all the services on this machine.

How about making a host netgroup that contains only the hosts that need access to all of the services, and referencing that in the hosts.allow file? Here's what it might look like:

goodhosts (opus,-,)(willy,-,)(cartman,-,)(stan,-,)(chef,-,)

You'll recognize opus and willy from the original hosts.allow file. The other hosts are those in the linuxlaboratory.org domain that need access to all services available on this machine. Now we can rewrite that nasty ALL line in our hosts.allow file:

#
# hosts.allow
#
ALL: @goodhosts,192.168.2.,192.168.3.

This is much easier to read, has less room for typos, and is a more restrictive security policy, since hosts have to be explicitly added to the netgroup to gain access, instead of inheriting access by virtue of their existence in something as large as a whole domain.

Netgroups and "compat mode"

Compat mode (short for "compatibility") lets you add NIS/NIS+ compatibility to an /etc/passwd or /etc/shadow file. It's pretty neat stuff, and netgroups make it especially cool.

Let's look at how to use netgroups and compat mode. First, define a user netgroup in LDAP or NIS or files -- whichever you use -- that contains only our most trusted users:

trustme (-,larry,)(-,curly,)(-,mojo,)

Next, we put an entry for this netgroup into our /etc/passwd file. Here's what the line looks like:

+@trustme

This effectively adds all of the users in the trustme netgroup to the /etc/passwd file. Now we just set up our /etc/nsswitch.conf file to use compat mode, which is what supports the parsing of the "+@" syntax in the /etc/passwd file:

passwd: files compat
passwd_compat: ldap

In the first line, we tell the system we're using files with compat mode to look up passwd information on a user. The second line tells us which naming service the compat mode information request is to be sent to. In our case, having files compat allows for a root account that's local to each machine and lives in the /etc/passwd file, while still allowing us to make use of an LDAP server for non-local accounts which are centrally maintained.

In closing

This is not an exhaustive list of uses for netgroups. They can be used for other things as well, not the least of which are things like your NFS exports file and other fields of your nsswitch file. Since netgroups have been around since the last Ice Age, many utilities at the system level already know what they are. Currently Linux has, by far, the best support for requesting netgroups from an LDAP server. The libraries that do the heavy lifting for Linux (OpenLDAP and PADL's nss_ldap) can also be installed on most Unix flavors -- good news for those of us in heterogenous environments!

Configuring and Using NFS Netgroups

Netgroup Examples The following netgroup specifies a group of hosts: trusted_hosts (sage, , ), (basil, , ), (thyme, , ) The trusted_hosts netgroup could be used in the -access option of a line in the /etc/exports file, as follows: /usr -access=trusted_hosts The following netgroup specifies a group of users: administrators ( ,jane, ), ( ,art, ), ( ,mel, ) If this netgroup were ever accidentally included in a list of hosts rather than users, the blank space would be interpreted as a wildcard meaning any host. For example, if someone used this netgroup in a -access list in the /etc/exports file, any host would have access to the exported directory. For this reason, if a netgroup is used strictly as a list of users, it is better to put a dash in the host field, as follows: administrators (-,jane, ), (-,art, ), (-,mel, ) The dash indicates that no hosts are included in the netgroup. The trusted_hosts and administrators netgroups could be used together in the /etc/hosts.equiv file, as follows: +@trusted_hosts +@administrators The first netgroup would be read for host names, and the second would be read for user names. Users in the administrators netgroup could log into the local host from any host in the trusted_hosts netgroup without supplying a password. The two netgroups could be combined into one, as follows: goodguys (sage,jane, ), (basil,art, ), (thyme,mel, ) If the two netgroups were combined this way, the same netgroup could be used as both the host name and the user name in the /etc/hosts.equiv file: +@goodguys +@goodguys The first occurrence of it would be read for the host name, and the second occurrence would be read for the user name. No relationship exists between the host and user in any of the triples. For example, user jane might not even have an account on host sage. A netgroup can contain other netgroups, as in the following example: root-users (dill,-, ), (sage,-, ), (thyme,- , ), (basil,-, ) mail-users (rosemary, , ), (oregano, , ), root-users The root-users netgroup is a group of four systems. The mail-users netgroup uses the root-users netgroup as part of a larger group of systems. The blank space in the third field of each triple indicates that these netgroups are valid in any NIS domain. To Use Netgroups in Configuration Files Netgroups may be used in the following files: /etc/exports, in the -access list /etc/hosts.equiv or $HOME/.rhosts, in place of a host name or user name /etc/passwd, to tell processes whether to look in the NIS password database for information about the users in the netgroup /etc/group, to tell processes whether to look in the NIS group database for information about the users in the netgroup The next few sections explain how to use netgroups in these files. Using Netgroups in the /etc/exports File In the /etc/exports file, netgroups can be used in the list of NFS clients following the -access option, as in the following example: /var/mail -access=mail_clients The mail_clients netgroup is defined as follows: mail_clients (cauliflower, , ), (broccoli, , ), (cabbage, , ) Only the host names from the netgroup are used. If the netgroup also contains user names, these are ignored. This netgroup is valid in any NIS domain, because the third field in each triple is left blank. Using Netgroups in the /etc/hosts.equiv or $HOME/.rhosts File In the /etc/hosts.equiv file, or in a .rhosts file in a user's home directory, netgroups can be used in either the host name field or the user name field, as in the following example: +@our_friends +@our_friends The netgroup our_friends can be used as both the host name and the user name, because it includes both host names and user names, as follows: our_friends (sage,sara, ), (sage,eric, ), (dill,-, ), ( ,monica, ) The blank host name field in the fourth triple serves as a wildcard, allowing users from any host on the network to log in without supplying a password. However, only the users listed in the netgroup are given this privileged access, because each user name field contains either a user name or a dash. Netgroups can also be used to deny privileged access to certain hosts or users in the /etc/hosts.equiv or $HOME/.rhosts file, as in the following example, + -@vandals The plus sign (+) is a wildcard in the /etc/hosts.equiv or $HOME/.rhosts file syntax, allowing privileged access from any host in the network. The netgroup vandals is defined as follows: vandals ( ,pat, ), ( ,harriet, ), ( ,reed, ) All users except those listed in the vandals netgroup can log into the local system without supplying a password from any system in the network. CAUTION: Any users who are denied privileged access in the /etc/hosts.equiv file can still be allowed privileged access in a user's $HOME/.rhosts file. The $HOME/.rhosts file is read after the /etc/hosts.equiv file and overrides it. For more information, type man 4 hosts.equiv at the HP-UX prompt. Using Netgroups in the /etc/passwd File In the /etc/passwd file, netgroups can be used to indicate whether user information should be looked up in the NIS passwd database. The following example line from the /etc/passwd file indicates that users in the netgroup animals should be looked up in the NIS passwd database: +@animals The animals netgroup is defined as follows in the /etc/netgroup file: animals (-,mickey, ), (-,daffy, ), (-,porky, ), (-,bugs, ) Note that the /etc/passwd file is searched sequentially, so if user mickey, daffy, porky, or bugs appears before the animals netgroup in the /etc/passwd file, the NIS database will never be consulted for information on that user. The Name Service Switch configuration is used to determine where to look for the contents of a netgroup. See Chapter 5 "Configuring the Name Service Switch". Netgroups can also be used to prevent lookups of certain users in the NIS passwd database. The following example lines from the /etc/passwd file indicate that if the NIS passwd database contains entries for users in the bears netgroup, these entries cannot be used on the local system. Any other users can be looked up in the NIS database. -@bears +::-2:60001::: The line beginning with + causes the NIS database to be searched for any users (except those in the bears netgroup) who are not listed before the line beginning with +. For more information on NIS, see Chapter 4 "Configuring and Administering NIS". For information on the /etc/passwd file, type man 4 passwd at the HP-UX prompt. Using Netgroups in the /etc/group File In the /etc/group file, netgroups can be used to indicate whether group information about certain users should be looked up in the NIS group database. The following example line from the /etc/group file indicates that group information for users in the netgroup animals can be found in the NIS group database: +@animals The animals netgroup is defined as follows in the /etc/netgroup file: animals (-,mickey, ), (-,daffy, ), (-,porky, ), (-,bugs, ) Members of the animals netgroup can belong to groups listed in the local /etc/group file as well as in the NIS group database. The following lines in the /etc/group file give users bugs and daffy membership in the group wiseguys and in any group in the NIS database that includes them as members: wiseguys::22:bugs,daffy +@animals Netgroups can also be used in the /etc/group file to prevent lookups for certain users. The bears netgroup is defined as follows in the /etc/netgroup file: bears (-,yogi, ), (-,smokey, ), (-,pooh, ) The following lines in the /etc/group file allow user pooh membership in group teddybears but not in any other group listed in the NIS database or after the -@bears line in the /etc/group file: teddybears::23:pooh,paddington -@bears For more information on NIS, see Chapter 4 "Configuring and Administering NIS". For information on the /etc/group file, type man 4 group at the HP-UX prompt.

[Chapter 19] 19.4 Sun's Network Information Service (NIS)

NIS netgroups allow you to create groups for users or machines on your network. Netgroups are similar in principle to UNIX groups for users, but they are much more complicated.

The primary purpose of netgroups is to simplify your configuration files, and to give you less opportunity to make a mistake. By properly specifying and using netgroups, you can increase the security of your system by limiting the individuals and the machines that have access to critical resources.

The netgroup database is kept on the NIS master server in the file /etc/netgroup or /usr/etc/netgroup. This file consists of one or more lines that have the form:

groupname member1 member2 ...

Each member can specify a host, a user, and a NIS domain. The members have the form:

(hostname, username, domainname) 

If a username is not included, then every user at the host hostname is a member of the group. If a domainname is not provided, then the current domain is assumed.[11]

[11] It is generally a dangerous practice to create netgroups with both users and hosts; doing so makes mistakes somewhat more likely.

Here are some sample netgroups:

Profs (cs,bruno,hutch) (cs,art,hutch)

This statement creates a netgroup called Profs, which is defined to be the users bruno and art on the machine cs in the domain hutch.

Servers (oreo,,) (choco,,) (blueberry,,)

This statement creates a netgroup called Servers, which matches any user on the machines oreo, choco, or blueberry.

Karen_g (,karen,)

This statement creates a netgroup called Karen_g which matches the user karen on any machine.

Universal(,,,)

This statement creates the Universal netgroup, which matches anybody on any machine.

MachinesOnly ( , - , )

This statement creates a netgroup that matches all hostnames in the current domain, but which has no user entries. In this case, the minus sign is used as a negative wildcard.

19.4.4.1 Setting up netgroups

The /etc/yp/makedbm program (sometimes found in /usr/etc/yp/makedbm) processes the netgroup file into a number of database files that are stored in the files:

/etc/yp/domainname/netgroup.dir 
/etc/yp/domainname/netgroup.pag 
/etc/yp/domainname/netgroup.byuser.dir 
/etc/yp/domainname/netgroup.byuser.pag 
/etc/yp/domainname/netgroup.byhost.dir 
/etc/yp/domainname/netgroup.byhost.pag

Note that /etc/yp may be symbolically linked to /var/yp on some machines.

If you have a small organization, you might simply create two netgroups: one for all of your users, and a second for all of your client machines. These groups will simplify the creation and administration of your system's configuration files.

If you have a larger organization, you might create several groups. For example, you might create a group for each department's users. You could then have a master group that consists of all of the subgroups. Of course, you could do the same for your computers as well.

Consider the following science department:

Math (mathserve,,) (math1,,) (math2,,) (math3,,) 
Chemistry (chemserve1,,) (chemserve2,,) (chem1,,) (chem2,,) (chem3,,) 
Biology (bioserve1,,) (bio1,,) (bio2,,) (bio3,,) 
Science Math Chemistry Biology

Netgroups are important for security because you use them to limit which users or machines on the network can access information stored on your computer. You can use netgroups in NFS files to limit who has access to the partitions, and in data files such as /etc/passwd, to limit which entries are imported into a system.

19.4.4.2 Using netgroups to limit the importing of accounts

You can use the netgroups facility to control which accounts are imported by the file /etc/passwd. For example, if you want to simply import accounts for a specific netgroup, then follow the plus sign (+) with an at sign (@) and a netgroup:

root:si4N0jF9Q8JqE:0:1:Mr. Root:/:/bin/sh +@operators::0:0:::

The above will bring in the NIS password map entry for the users listed in the operators group.

You can also exclude users or groups if you list the exclusions before you list the netgroups. For example:

root:si4N0jF9Q8JqE:0:1:Mr. Root:/:/bin/sh -george::120:5::: -@suspects::0:0::: +::0:0:::

The above will include all NIS password map entries except for user george and any users in the suspects netgroup.

NOTE: The +@netgroup and -@netgroup notation does not work on all versions of NIS, and does not work reliably on others. If you intend to use these features, check your system to verify that they are behaving as expected. Simply reading your documentation is not sufficient.

How netgroups affect security on an NIS network

On a network with NIS, the netgroup input file on the master NIS server is used to generate three NIS maps: netgroup, netgroup.byuser, and netgroup.byhost. The NIS map netgroup contains basic information in the netgroup input file. The other two maps contain information in a format that speeds lookup of netgroups, given the host or user.

Various programs use the netgroup NIS maps for permission checking during login, remote mount, remote login, and remote shell creation. These programs include: mountd(1Mnfs), login(1), rlogin(1tcp), and rsh(1tcp). The login command consults them for user classifications if it encounters netgroup names in the passwd file. The mountd daemon consults them for machine classifications if it encounters netgroup names in the netgroup file. The rlogin and rsh commands consult the netgroup maps for both machine and user classifications if they encounter netgroup names in the /etc/hosts.equiv or .rhosts file. For more information about netgroups, refer to the netgroup(4nis) manual page.

Recommended Links

Softpanorama Recommended

Top articles

Sites

Configuring and Using NFS Netgroups

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 12, 2019