Unix/Linux run levels

See Wikipedia entry.

Standard Unix/Linux run levels

OS X – Change hostname permanently

sudo scutil –set HostName tracy.dynalias.net

OS X – Enabling Root user – Tiger

Quick Method using NetInfo Manager
This is the easiest method if you are more of a GUI person.
1.    Log in on the Admin account.

2.    Start the NetInfo Manager application, which is in the Application/Utilities folder:† Macintosh†HD -> Applications -> Utilities -> NetInfo†Manager.
3.    If you don’t have this in the dock for the Admin account you should probably drag it there. It is very useful for system administration.

4.    From the top menu bar pull down the “Security” item and select “Enable root user”. You will have to enter the administrator’s password to authenticate yourself.

Linux – Managing Users and Groups

Commands to manage users In Linux

To add a user

adduser -m -g PRIMARY_GROUP -G  ADDITIONAL_GROUPS -s /bin/bash -c "USER REAL INFO" USER

Options:

• -d home directory
• -s starting program (shell)
• -p password
• -g (primary group assigned to the users)
• -G (Other groups the user belongs to)
• -m (Create the user’s home directory

To update a user

usermod -m -g PRIMARY_GROUP -G  ADDITIONAL_GROUPS -s /bin/bash USER

Options:

• -d home directory
• -s starting program (shell)
• -p password
• -g (primary group assigned to the users)
• -G (Other groups the user belongs to)

To delete a user

userdel -r USER

Options:

• -r remove home directory

To add a group

groupadd [-g GROUP_ID] GROUP_NAME

Related commands:

• useradd – Add a user to a group
• userdel – Remove a user from a group
• groupdel – Delete a group

Managing I/O ports

Listing open ports

lsof -i -P -n

netstat CLOSE_WAIT clear port

lsof -i tcp:5000

First – one should _never_ need to use the ndd tcp_disconn kludge. Yes, never is a bit strong, but slip a digit somewhere and knuth only knows what you may fubar.

Modulo the unlikely event of a bug in the TCP stack (brings the usual song and dance about being on the latest transport patch…) a CLOSE_WAIT is the “fault” of the _application_.

CLOSE_WAIT is the state a TCP connection enters when it has recieved a FIN from the remote TCP, has ACKed that FIN and has sent a connection close indication up to the application. TCP is now waiting for the application to call either close() or shutdown().

So, CLOSE_WAITs hanging around are the fault of the application, and the application should be fixed.

Going further, if the reason to terminate the CLOSE_WAITs is to allow a server application to be restarted, that suggests _another_ bug in the application – that the application is not setting SO_REUSEADDR before trying to bind() to its well-known port number(s). This too should be fixed in the application.

It may also mean that the application is broken in that it forks without both parent and child remembering to call close()…

So, while the tone may be a bit strident, definitely seek to have the application fixed before you resort to kludges.

BTW, the state one sees when remotes forget to send a FIN is FIN_WAIT_2 – where the local application has called shutdown or close, but the remote has not, or has used (bogusly) an abortive close and the RST has been lost.

Crontab format

See Wikipedia

# +---------------- minute (0 - 59)
# |  +------------- hour (0 - 23)
# |  |  +---------- day of month (1 - 31)
# |  |  |  +------- month (1 - 12)
# |  |  |  |  +---- day of week (0 - 6) (Sunday=0 or 7)
# |  |  |  |  |
  *  *  *  *  *  command to be executed