|
|
Extracted from Professor Nikolai Bezroukov unpublished lecture notes.
Copyright 2010-2018, Dr. Nikolai Bezroukov. This is a fragment of the copyrighted unpublished work. All rights reserved.
There two way to specify authentication in Linux -- via local files and via LDAP. Here we will discuss using local files for configurting authentication.
Local files are good tpobably upto 256 users, after that LDAP should generally be used. But after LDAP now is used as the default method of authentication in all cases.
- Manage users and groups
- Create, delete, and modify local user accounts
- Change passwords and adjust password aging for local user accounts
- Create, delete, and modify local groups and group memberships
- Configure a system to use an existing authentication service for user and group information
The main problem with Unix is not that root is too powerful, but that the users accounts are not powerful enough to permit users to perform the necessary tasks. That's why the classic Unix permission structure was expended with ACL, which represents a hack that allows uses to access selected files and sudo which is another hacks: an attempt to implement "poor man RBAC" (role based access control) tool. Solaris implemented RBAC in kernel more then 15 years ago.
To get information about a user account, you can use the id command. When using this command from the command line, you can see details about the current user. You can also use it on other user accounts to get details about those accounts:
id bezroun
Also useful is whoami command:
whoami bezroun
NOTE: Working as root is dangerous. There is a the whole folklore about spectacular blunders committed by sysadmins. See Sysadmin Horror Stories. For some such blunders cost employment.
On all Linux systems, by default there only one provided accounts with UID 0. Traditionally it is called root. It has primary group root with GID 0. This account is necessary for managing Linux because for many administrative tasks root privileges are required. Some examples are installing software, managing users, and creating partitions on disk devices. Generically speaking, all tasks that involve direct access to devices need root permissions.
Due to the fact that it has privileges to do anything, sometimes root is called superuser.
There might be several accounts with UID 0 in Linux, end each of them is root, no matter what username is uses. But this is a bad practice which should be avoided. And often is detected by security tools.
Some people have a bad habit of logging in as root directly. That is not recommended, especially when you are logging in to a graphical environment. When you log in as root in a graphical environment, all tasks that are executed are running as root as well, and that involves an unnecessary security risk.
But even on command line working as root represent significant risk of wiping out files on the system or performing the operation as root on a wrong server (for example reboot the system). Look at Sysadmin Horror Stories. So it should be avoided.
Terminal sessions in which you are root should be clearly marked with special background color, for example bright yellow, to distinguish then from regular sessions. You might also take other precaution because for example performing operation as a root on a wrong server. for example if you have multiple displays you might move root session to a particular
The su command allows to switch the identity. To perform administrative tasks, for instance, you can log in with a normal user account and type "su - " to open a root shell when you need to perform some operations as root. Or you want to assume other user identity to troubleshoot the problems this user is experiencing.
If just the command su - is typed, the username root is implied. But su - can be used to run tasks as another user as well. For example, you can type su - joeuser to assume identity of the user joeuser. The command opens subshell and to exit you just need to type exit. You will return into identity and environment you have had before.
When using su - as an ordinary user, you will be prompted for a password:
[joeuser@localhost ~]$ su -
Password:
[root@localhost joeuser]#
If you omit "-" in su command, you inherit the environment of the current user (for example root). This is not desirable and you should always use su with "-" to get target user environment for debugging. In this case all scripts that make up the user environment are executed, which creates for you an environment, which is exactly the same as when you log in as this particular user.
TIPS:
Sudo utility is crutches designed to add some elements of RBAC access to Linux. Among other things it allow "delegation" of root privileges to selected users.
One typical way to use sudo is to configure it so that members of the group wheel are allowed to became root. This practice comes from FreeBSD and was adopted for Linux despite the fact that on Linux wheel is not a special system group, but is a regular group.
Another important use of sudo it to grant ordinary users the ability to execute certain commands as root. This is a tricky business as many commands allow your to open shell and granting ability to execute them as root is equivalent to the ability to switch to root. But as I said before sudo is a hack, and we can't expect much form a hack. Solaris stating from version 10 have real RBAC capability (sing probably year 2000) so I hope that eventually they will be re-completed in Linux. It took linux approximately 15 years to re-implement Solaris zones (as containers), so even for much more complex ideas re-implementation seems possible despite large differences in kernel architectures.
NOTE: when you assign specific command to be executed as root by non-privilege users but this is more evolved, as you need to be sure that those command can't launch shell session or make changes to the system which allow the user to get root access. For example it is a bad idea to grant users ability to invoke vi as root. but many books authors do not understand that even "innocently looking" commands like useradd or cp should not be grated to ordinarily users. In case of the useradd command a non-privileged user obtains the ability to create a new account with UID 0 which pretty obvious consequences. In case of cp situation is more tricky but the ability to copy a command with the SUID bit set to the directory which he owns (for example his home directory) is dangerous.
Although wheel group exists in Red Hat 7 by default (and has GID 10) the ability of the members of wheel group to became root is not the default setting in Red Hat and needs to be explicitly configured.
## Same thing without a password %wheel ALL=(ALL) NOPASSWD: ALL
There are two main files involved in authentication of users with local files: /etc/passwd and /etc/shadow
There are also a couple of additional file /etc/passwd- is a backup of /etc/passwd maintained by some tools,
see the man page. There's also a /etc/shadow-
usually, for the same purpose. another similar file is gshadow with gshadow- as a backup.
If you have similar server and which to save yourself from setting up accounts again you need to copy all those files.
This file is human readable file which contains the database of users on system. Fields in records of the database are separated by ':' (colon).
By default /etc/passwd file permissions is 644 i.e. -rw-r--r-- and ownership root:root.
That means that this file is world readable, but only root can edit it.
It is possible, however it is not recommended, to edit this file manually.
Each line is a record which defines one user and consists of 7 fields:
NOTE: A file /etc/nologin can be created. If this file exists, only root will be able to log in. Other users will see the contents of this file and logins will be denied.
The /etc/shadow file stores the hash of the password (the result of encoding of a string containing 8 blanks using this password, not the password itself) in encrypted form for user’s account with additional properties related to user password. Only the root can read this file.
Storing hash means that it is impossible to decrypt this hash using any method other then trial and error (brute force decoding or as it called cracking the password). This was a very pretty elegant idea, that survived the test of the time. the string that is used for encoding the password consists of "salt" (a two-character random string) and blanks. Salt is prefixed to the hash value, so that hashing can be reproduced on supplied password.
Earlier versions of Unix used a password file
/etc/passwdto store the hashes of salted passwords (passwords prefixed with two-character random salts). In these older versions of Unix, the salt was also stored in the passwd file (as cleartext) together with the hash of the salted password. The password file was publicly readable for all users of the system. This was necessary so that user-privileged software tools could find user names and other information. The security of passwords is therefore protected only by the one-way functions (enciphering or hashing) used for the purpose. Early Unix implementations limited passwords to eight characters and used a 12-bit salt, which allowed for 4,096 possible salt values.[4] This was an appropriate balance for 1970s computational and storage costs.[5]... ... ...
The shadow password system is used to limit access to hashes and salt. The salt is eight characters, the hash is 86 characters, and the password length is unlimited.
But it does not prevents downloading /etc/password file by regular users and running password cracker on them. Generally password that are a dictorary word or have length less then 8 and which doe not have one upper case letter and one delimiter (like "!@%^&*()" ) and include letter and number are considered weak. In a sense that they can be cracked.
The simplest way to prevent this possibility is to increase the size of alphabet as the total number of letters in the alphabet is the power to which length of password is raised to obtain number of possible combinations. Usage all symbols on keyboard (and that's why one or more upper case letters, digits and special symbol are required) gives us alphabet consisting of 24*2 (letters)+10 (digits)+32(special symbols)=90 symbols. And, say, 8**90 which is equal to 2**270 is a tremendous number which is larger then the number of atoms in the universe (the number of atoms in the Universe is between 10**78 and 10**82 or around 2**100) Remember that in the famous fable about chess the number is just 2**64.
One ancient legend that many children might even find in their maths books is about the tyrannical Indian king, Shihram, and a wise man in his kingdom. The wise man wanted to convince Shihram of the importance of each resident of his kingdom.
So, he invented a game to represent the kingdom consisting of the king himself, his queen, rooks, bishops, knights, and pawns, all of which were important.
The king liked the game very much and understood that the game was just like real life. So, he ordered everybody in his kingdom to play chess! Shihram offered the man all the gold and silver that he wanted, but the wise man didn’t want any treasure.
Together with the king, he went to a chess board and asked him to put one grain of wheat on the first square, two on the second and to keep doubling it until the chessboard was full.
First of all, the king felt highly offended, but then he ordered his servants to fulfill the man’s wish. Desperately, the servants conveyed that such an enormous amount of wheat did not exist!
The king understood that the wise man had given him a second lesson. Just like the pawns in chess, you should never underestimate the small things in life!
It is a bad practice to have a single password for all servers you have access. It should vary by using some rule/ You cn also use Casio watches of application like Password Vault on you cell phone to store your passwords. Which, of course, is less secure :-)
In linux /etc/shadow stores password hash and password and account expiration information. All fields are separated by a colon (:) symbol. It contains one entry per line for each user listed in /etc/passwd file.
Most accounts attributes properties is stored in the fields of /etc/passwd database. But due to security consideration passwd is now stored in a special file called /etc/shadow. An example of /etc/shadow contents.
[0]d620@ROOT:~ # cat /etc/shadow root:$6$KAuIPpejmSlsUvOm$l/VZMXtF20NcVe7PYmW7Vs3Wam6JwLxy/DABnMaLujj2/pnDc/bO9VwP44dm9k9BofVk5jByLfqZ...::0:99999:7::: bin:*:17632:0:99999:7::: daemon:*:17632:0:99999:7::: adm:*:17632:0:99999:7::: lp:*:17632:0:99999:7::: sync:*:17632:0:99999:7::: shutdown:*:17632:0:99999:7::: halt:*:17632:0:99999:7::: mail:*:17632:0:99999:7::: operator:*:17632:0:99999:7::: games:*:17632:0:99999:7::: ftp:*:17632:0:99999:7::: nobody:*:17632:0:99999:7::: systemd-network:!!:17837:::::: dbus:!!:17837:::::: polkitd:!!:17837:::::: sshd:!!:17837:::::: postfix:!!:17837:::::: chrony:!!:17837::::::
Most of the password properties stored in /etc/shadow file can be managed with the passwd or chage commands
Unlike password file, shadow file is not world readable. It can be read by root user only. Shadow file permissions are 400 i.e.
-r-------- and ownership is root:root. Which means it can be only read by root users only. This is done to
increase security and prevent the possibility of brute force attach on password using password crackers, which is possible if password
is stored in /etc/passwd (this file is world readable).
The following fields are defined in /etc/shadow:
NOTE:
username:!!:
or
username:!!$1$MvGJq5Nq$ersjw/IaU90l.n5sB/FFP1:
The command passwd -l username will lock the user username by putting !! as a prefix
After command passwd -u username, prefix !! disappears.
On a typical Linux environment, two kinds of user accounts exist. There are user accounts for the people who need to work on a server and who need access to the resources on that server. These user accounts typically have a password that is used for authenticating the user to the system. There are also system accounts that are used by the services the server is offering or for the separation of file space on the server. Nobody need to login to those account and such accounts typically do not have a valid shell. The latter accounts are called system account that they should not contains a valid shell in /etc/passwd file. Instead a dummy shell, typically /sbin/nologin (but sometimes /bin/false) is used.
Both user accounts share common properties, which are kept in the files /etc/passwd and /etc/shadow. Minimal installation of Red Hat 7 contains 19 accounts:
# cat /etc/passwd root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin adm:x:3:4:adm:/var/adm:/sbin/nologin lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin sync:x:5:0:sync:/sbin:/bin/sync shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown halt:x:7:0:halt:/sbin:/sbin/halt mail:x:8:12:mail:/var/spool/mail:/sbin/nologin operator:x:11:0:operator:/root:/sbin/nologin games:x:
Number of users on a typical server fluctuates and managing the set of user whoa re able to access particular server is an important part of responsibilities of any sysadmin. Especially important is to delete or disable the users who left the company.
In any case on a typical server some users are added, some deleted on a regular basis.
Many users have access to multiple server and there is need to coordinate their access
to all those servers. Previously this was done via NIS, in modern days -- via LDAP. If you servers are homogeneous you do this with local files distributing them with so parallel execution programs. If the servers are not homogeneous and run substantially different flavors of Linux you need to use scripts that convert passwd file into a set useradd/usermod/userdel commands that eliminates the differences.
Unless you need to manage hundreds of server and have let's say less then hundred of users on each you can still manage multiple servers using local files.
12:100:games:/usr/games:/sbin/nologin ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin nobody:x:99:99:Nobody:/:/sbin/nologin systemd-network:x:192:192:systemd Network Management:/:/sbin/nologin dbus:x:81:81:System message bus:/:/sbin/nologin polkitd:x:999:998:User for polkitd:/:/sbin/nologin sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin postfix:x:89:89::/var/spool/postfix:/sbin/nologin chrony:x:998:996::/var/lib/chrony:/sbin/nologin
NOTE:
Sometimes instead of a shell some application that provides information is used. For example command uptime can be used this way
uptime:x:1000:1000:user:/tmp:/uptimeBut this is quite artificial and somewhat unrealistic example. Typically a program or script that present to user the menu of several actions is displayed and used can chose only one of those options.
You can manually edit the contents of the /etc/passwd and /etc/shadow files to add users (with the risk of making an error that could make logging in impossible to anyone). You can also copy records from the other server to the corresponding files (or even copy all the files)
But the normal way to add users is useradd utility. To remove users, you can use the userdel command. Use userdel -r to remove a user, including the complete user environment (home directory, mail, etc).
There are several additional problems that arise then you manage multiple servers and a particular user has login rights on several or all of them:
that's why LDAP is typically used to authenticate user to multiple servers. In the past NIS was used.
When you add a new user accounts, one line is added to /etc/passwd and to /etc/shadow. While you can add them manually too, it is not recommended. By making an error, you might make log in impossible to anyone.
If there are many users and multiple sysadmins you also might encounter locking problems when you are trying to modify the file directly and some tool or another sysadmin also try to modify it adding or modifying another account. So if you need to edit file directly please use vipw command. which sets the appropriate locks to prevent corruption. It does not check syntax. In most cases it is safer to use useradd and groupmod. Making some typos to can disable login for all users including root. To edit the contents of the /etc/group file where groups are defined, a similar command with the name vigr exists. It is more or less safe to edit /etc/group directly.
Note:
Some errors introduced by manual editing are very subtle and are not detected by system as errors but just change the behaviors of the account.
The useradd utility allows you to add a user account from the command line. It has many parameters (consul man page for the list). The default values are set in two configuration files: /etc/login.defs and /etc/default/useradd. The main options for this command are listed below:
For example the command
useradd -m -u 10010 -g 100 -G researchers -d /users/home joeuser
creates a user joeuser who is a member of the groups researchers with UID 10010 and add a home directory /users/home/joeuser to the user account as well.
Content of /etc/skel will be copied to the directory after it is created and ownership of those files and directories will be changed appropriately.
All normal users have a home directory. Usually it is create as a subdirectory of the /home directory but your setup can be different and other directory can be used. It can be specified as default in /etc/default/useradd.
Home directory for the user aslos can be specified explicitly in the useradd command using option -d.
For example in computations clusters user directories are typically put on NFS or GPFS filesystems and the relevant directory can be /gpfs/users. In this case you can use the command
useradd -g 10001 -g 10001 -m -d /gpfs/users joeuser
useradd command will create home directly in two cases:
If home directory is created the content of the /etc/skel directory is copied to the user home directory. These files will also get the appropriate permissions to ensure that the new user can use and access them.
By default, the skeleton directory contains mostly configuration files that determine how the user environment is set up. If in your environment specific files need to be present in the home directories of all users, you should add the files to the /etc/skel directory.
By default /etc/skel contains two dot files which should be modified to include relevant for particular server settings which are needed for all users:
When logging in, the files are read in this order, and variables and other settings that are defined in these files are applied. If a variable or setting occurs in more than one file, the last one wins.
Utility useradd uses two file with some default values: /etc/login.defs and /etc/default/useradd. The default content of the file /etc/default/useradd is as following:
[root@localhost skel]# cat /etc/default/useradd
# useradd defaults file GROUP=100 HOME=/home INACTIVE=-1 EXPIRE= SHELL=/bin/bash SKEL=/etc/skel CREATE_MAIL_SPOOL=yes
In the file /etc/login.defs, several other login-related variables are set. This file is used not only by useradd, but by several different commands. It specify setting up the appropriate environment for all new users.
Here is a list of some of the most significant properties that can be set from /etc/login.defs:
The default content is as following:
[0]d620@ROOT:~ # cat /etc/login.defs # # Please note that the parameters in this configuration file control the # behavior of the tools from the shadow-utils component. None of these # tools uses the PAM mechanism, and the utilities that use PAM (such as the # passwd command) should therefore be configured elsewhere. Refer to # /etc/pam.d/system-auth for more information. # # *REQUIRED* # Directory where mailboxes reside, _or_ name of file, relative to the # home directory. If you _do_ define both, MAIL_DIR takes precedence. # QMAIL_DIR is for Qmail # #QMAIL_DIR Maildir MAIL_DIR /var/spool/mail #MAIL_FILE .mail # Password aging controls: # # PASS_MAX_DAYS Maximum number of days a password may be used. # PASS_MIN_DAYS Minimum number of days allowed between password changes. # PASS_MIN_LEN Minimum acceptable password length. # PASS_WARN_AGE Number of days warning given before a password expires. # PASS_MAX_DAYS 99999 PASS_MIN_DAYS 0 PASS_MIN_LEN 5 PASS_WARN_AGE 7 # # Min/max values for automatic uid selection in useradd # UID_MIN 1000 UID_MAX 60000 # System accounts SYS_UID_MIN 201 SYS_UID_MAX 999 # # Min/max values for automatic gid selection in groupadd # GID_MIN 1000 GID_MAX 60000 # System accounts SYS_GID_MIN 201 SYS_GID_MAX 999 # # If defined, this command is run when removing a user. # It should remove any at/cron/print jobs etc. owned by # the user to be removed (passed as the first argument). # #USERDEL_CMD /usr/sbin/userdel_local # # If useradd should create home directories for users by default # On RH systems, we do. This option is overridden with the -m flag on # useradd command line. # CREATE_HOME yes # The permission mask is initialized to this value. If not specified, # the permission mask will be initialized to 022. UMASK 077 # This enables userdel to remove user groups if no members exist. # USERGROUPS_ENAB yes # Use SHA512 to encrypt password. ENCRYPT_METHOD SHA512
For changing user properties, the same rules apply as for creating user accounts. You can either work directly in the configuration files using vipw or you can use command-line tools.
The ultimate command-line utility for modifying user properties is usermod. It can be used to set all properties of users as stored in /etc/passwd and /etc/shadow, plus some additional tasks, such as managing group membership. There is just one task it does not do well: setting passwords.
usermod has an option -p that tells you to "use encrypted password for the new password." This parameter allow you propagate exiting encoded password from one server to another. So it is useful when you want to set the same password for the user on multiple servers.
From the list of /etc/shadow fields it is clear that password aging parameters are set in /etc/shadow. You can use two commands to change these fields: chage and passwd.
For instance, the command passwd -i 30 -w 3 -x 90 joeuser sets the password for user joeuser to a 30 days of inactivity before account is locked and a password expiration period of 90 days, where a warning is generated 3 days before expiry.
Many of the tasks that can be accomplished with passwd can be done with chage also. Options are slightly different though ;-)
Chage command is convenient for temporary account as you can specify, for instance, use chage -E 2018-12-31 joeuser to have the account for user bob expire on December 31, 2018.
To see current password aging settings for a particular user, use chage -l
[127] d620@ROOT:/home # chage -l student1 Last password change : Dec 07, 2018 Password expires : never Password inactive : never Account expires : never Minimum number of days between password change : 0 Maximum number of days between password change : 99999 Number of days of warning before password expires : 7
In this exercise, you apply common solutions to create user accounts.
for i in `seq 1 9` ; do useradd -u 10000$i student$i; done
for i in `seq 1 9` ; do userdel -r student$i; done
Every Linux user has to be a member of at least one group which is called primary group. This group is specified in /etc/passwd, not in /etc/group file, but it should exist in /etc/group when you create the account for the users, unless "user private group" mode is specified. There is only one primary group. When creating files owned by this user, the primary group becomes group owner of these files.
Users can also access all files their primary group has access to. The user’s primary group membership is defined in /etc/passwd; the group itself is stored in the /etc/group configuration file.
Besides the mandatory primary group, users can be a member of one or more secondary groups as well. Secondary groups are important to get access to files. If the group a user is a member of has access to specific files, the user will get access to these files also. Working with secondary groups is important, in particular in environments where Linux is used as a file server to allow people working for different departments to share files with one another.
As is the case for creating users, there are also different options for creating groups. The group configuration files can be modified directly using vigr or the command-line utility groupadd.
With the vigr command, you open an editor interface directly on the /etc/group configuration file.
Here is default set of groups in RHEL 7. After minimal installation it contains 46 groups, which is probably way to many:
[0]d620@ROOT:/etc/skel # cat /etc/group root:x:0: bin:x:1: daemon:x:2: sys:x:3: adm:x:4: tty:x:5: disk:x:6: lp:x:7: mem:x:8: kmem:x:9: wheel:x:10: cdrom:x:11: mail:x:12:postfix man:x:15: dialout:x:18: floppy:x:19: games:x:20: tape:x:33: video:x:39: ftp:x:50: lock:x:54: audio:x:63: nobody:x:99: users:x:100: utmp:x:22: utempter:x:35: input:x:999: systemd-journal:x:190: systemd-network:x:192: dbus:x:81: polkitd:x:998: ssh_keys:x:997: sshd:x:74: postdrop:x:90: postfix:x:89: chrony:x:996:
The following fields are used in /etc/group:
Another method to create new groups is by using the groupadd command. For example
groupadd -g student1 10001
To manage group membership you can iether edit file directly or use groupmod command. You can use this command to change the name or group ID of the group, but unfortunately it does not allow you to add group members. To do this, you need to use usermod command instead. The command usermod -aG will add users to the group specified as the argument.
That's why it is quite common that group membership is edited directly in the /etc/group file by using the vigr command.
Tip:
Each user group membership is defined in two different locations:
- the primary group is specified in /etc/passwd, not /etc/group,
- All other groups memberships (we can call then secondary memberships) are specified in /etc/group.
You can list of members in a particular group you can used special command -- groupmems. It shows both the users who are a member of this group as a secondary group assignment, but also users who are a member of this group as the primary group assignment.
|
|
Switchboard | ||||
| Latest | |||||
| Past week | |||||
| Past month | |||||
Google matched content |
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: December 13, 2020