Aug 142012
If you want to find the system ID of the user type:
	id username

You can check what groups a user belongs to by using the "groups" command.
	groups <username>

To create a user with the default groups type:
	sudo adduser --add_extra_groups username
        Fedora: sudo adduser -m username

To delete a user and its primary group type:
	sudo deluser username

To add an existing user to an existing group type:
	sudo usermod -a -G thegroupname theusername
	sudo usermod -a -G thegroupname theusername
	sudo useradd -G thegroupname theusername

Use gpasswd:
	sudo gpasswd -a theusername thegroupname

To remove user billybob from the group hillbilly.
	gpasswd -d billybob hillbilly

To give user billybob administrative rights to the group hillbilly.
	gpasswd -A billybob hillbilly

To Change a users primary group type:
	useradd -g www joebob

To show users that are in a group named joebob type:
	getent group joebob

To temporarily lock or unlock a user account, use the following syntax, respectively: 
	sudo passwd -l username 
	sudo passwd -u username 

If you want to use the GUI you will have to install the gnome-system-tools 
	sudo apt-get install gnome-system-tools 

Here are a few ways to run it once it is installed type: 
	sudo users-admin 
Press Alt+F2 
	sudo users-admin 
Press Enter. Press Ctrl+Alt+T. 
	sudo users-admin
Press Enter. 

If you want to add a group type: 
	sudo groupadd foo 
	sudo addgroup groupname 

If you want to delete a group type: 
	sudo delgroup groupname 

User Profile Security when a new user is created, the adduser utility creates a 
brand new home directory named /home/username, respectively. The default profile 
is modeled after the contents found in the directory of /etc/skel, which includes 
all profile basics. If your server will be home to multiple users, you should pay 
close attention to the user home directory permissions to ensure confidentiality. 
By default, user home directories in Ubuntu are created with world read/execute 
permissions. This means that all users can browse and access the contents of other 
users home directories. This may not be suitable for your environment. 

To verify your current users home directory permissions, use the following syntax: 
	ls -ld /home/username 

	The following output shows that the directory /home/username has world 
readable permissions: drwxr-xr-x 2 username username 4096 2007-10-02 20:03 username 
You can remove the world readable permissions using the following syntax: 
	sudo chmod 0750 /home/username 

Some people tend to use the recursive option (-R) indiscriminately which modifies 
all child folders and files, but this is not necessary, and may yield other 
undesirable results. The parent directory alone is sufficient for preventing
unauthorized access to anything below the parent. A much more efficient approach 
to the matter would be to modify the adduser global default permissions when creating 
user home folders. Simply edit the file /etc/adduser.conf and modify the DIR_MODE 
variable to something appropriate, so that all new home directories will receive the 
correct permissions. 

After correcting the directory permissions using any of the previously mentioned 
techniques, verify the results using the following syntax: 
	ls -ld /home/username 

The results below show that world readable permissions have been removed: 
drwxr-x--- 2 username username 4096 2007-10-02 20:03 username Password Policy A 
strong password policy is one of the most important aspects of your security posture. 
Many successful security breaches involve simple brute force and dictionary attacks 
against weak passwords. If you intend to offer any form of remote access involving 
your local password system, make sure you adequately address minimum password 
complexity requirements, maximum password lifetimes, and frequent audits of your 
authentication systems. Minimum Password Length By default, Ubuntu requires a minimum 
password length of 4 characters, as well as some basic entropy checks. These 
values are controlled in the file /etc/pam.d/common-password, which is outlined 
below. password required nullok obscure min=4 max=8 md5 If you would 
like to adjust the minimum length to 6 characters, change the appropriate variable 
to min=6. The modification is outlined below. password required nullok 
obscure min=6 max=8 md5 The max=8 variable does not represent the maximum length of 
a password. It only means that complexity requirements will not be checked on 
passwords over 8 characters. You may want to look at the libpam-cracklib package for 
additional password entropy assistance. Password Expiration When creating user 
accounts, you should make it a policy to have a minimum and maximum password age 
forcing users to change their passwords when they expire. 

To easily view the current status of a user account, use the following syntax: 
	sudo chage -l username 

The output below shows interesting facts about the user account, namely that there 
are no policies applied: Last password change : Jan 20, 2008 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 To set any of these values, 
simply use the following syntax, and follow the interactive prompts: 
	sudo chage username 

The following is also an example of how you can manually change the explicit 
expiration date (-E) to 01/31/2008, minimum password age (-m) of 5 days, maximum 
password age (-M) of 90 days, inactivity period (-I) of 5 days after password 
expiration, and a warning time period (-W) of 14 days before password expiration. 
sudo chage -E 01/31/2008 -m 5 -M 90 -I 30 -W 14 username To verify changes, use the 
same syntax as mentioned previously: 
	sudo chage -l username 

The output below shows the new policies that have been established for the account: 
	Last password change : Jan 20, 2008 
	Password expires : Apr 19, 2008 
	Password inactive : May 19, 2008 
	Account expires : Jan 31, 2008 
	Minimum number of days between password change : 5 
	Maximum number of days between password change : 90 
	Number of days of warning before password expires : 14 

Other Security Considerations Many applications use alternate authentication 
mechanisms that can be easily overlooked by even experienced system administrators. 
Therefore, it is important to understand and control how users authenticate and gain 
access to services and applications on your server. SSH Access by Disabled Users 
Simply disabling/locking a user account will not prevent a user from logging into 
your server remotely if they have previously set up RSA public key authentication. 
They will still be able to gain shell access to the server, without the need for any 
password. Remember to check the users home directory for files that will allow for 
this type of authenticated SSH access. e.g. /home/username/.ssh/authorized_keys. 
Remove or rename the directory .ssh/ in the user's home folder to prevent further 
SSH authentication capabilities. Be sure to check for any established SSH connections 
by the disabled user, as it is possible they may have existing inbound or outbound 
connections. Kill any that are found. Restrict SSH access to only user accounts that 
should have it. 

For example, you may create a group called "sshlogin" and add the group name as the 
value associated with the AllowGroups variable located in the 
file /etc/ssh/sshd_config. 
	AllowGroups sshlogin 

Then add your permitted SSH users to the group "sshlogin", and restart the SSH service. 
	sudo adduser username sshlogin 
	sudo /etc/init.d/ssh restart 

MakeUser Function for .bashrc file:

  makeuser () { 
  if [ $# -eq 0 ] 
  echo "Usage: makeuser username." 
  sudo adduser --add_extra_groups $1 

Source for most of this document:

Dec 222010

There are two main components of a UDT token and four basic parts. The two main components are “The CCL Script” and “The HTML Summary Template” that the token is embedded in. The four basic parts are: “The Setup”, “The Brains”, “The Token Build”, and “The Packaged”.

The setup:

Record Structure

record reply(

1 text = vc

1 format = i4


The Brains:

The “Brains” is simply a select statement that requests data.

There are only three valid requests that will allow the “Brains” of the program to access the Millennium database. Those requests are:

1. Request->encntr_id

2. Request->person_id

3. Request->tracking_id

The reserved word “DETAIL” delineates the “DETAIL CLAUSE”. The Detail clause puts the result into a format that Discern Explorer can work with.

The “Token Build”

When building the token, the objective is to gather up all the data taken from the database and piece it together in the coding equivalent of a sentence or string. The string is what the program is going to send back to an HTML Summary Template in FirstNet.

The key reserved words to identify the “Token Build” section of the program are not surprisingly the CCL Build() function, or the very similar CCL concat() function. Between the parenthesis “()” of the concat() and build() functions, is where the single or multiple token data items are going to be “built” for final delivery to FirstNet.

The “Packaged Token”

The last few lines of the UDT program will fill the token.

set reply-> text = boxed up token string in the form of a single variable.

set reply-> format = 1

“Reply->text”: This is a blob of text (built token stored in Drawer 1) that will contain information to pass/deliver to the front end which is FirstNet. The text must be formatted in HTML as a single string of text, which means a single “boxed” variable as stated before.

“Reply->format”: This defines the format of the text stored in Drawer 1. By setting format equal to 1 (format = 1) the token string’s format is equal to HTML. Why is this important? This is important, because what type of files are the Patient and or Clinical Discharge Summary Templates? Each Summary Template is an HTML file. By setting “reply-> format = 1” the HTML Summary Templates know how to handle the string of text sent by the UDT program.

If you want to run your CCL program and see what the HTML looks like you will have to execute it from another program “Answer File” that provides the information required in the “Brains” section.

Here is an example of an AnswerFile.prg:

free record request go

record request

( 1 encntr_id = f8

) go

set request->encntr_id= 43808766.00 go

execute 1bh_vaccine_udt go

After you run the “Answer File” file you will have to click the “List” button to see the HTML output.

Sep 072010

It’s possible to use even more complicated syntax with regular expressions:

I used this in my FTP script for safety surveillor.

case “$1? in
+(start|run) ) /usr/app/startup-script ;;
@([Ss])top ) /usr/app/stop-script ;;

?(pattern1 | pattern2 | … | patternn)
zero or one occurrence of any pattern

*( pattern1 | pattern2 | … | patternn)
zero or more occurrences of any pattern

@( pattern1 | pattern2 | … | patternn)
exactly one occurrence of any pattern

+( pattern1 | pattern2 | … | patternn)
one or more occurrence of any pattern

!( pattern1 | pattern2 | … | patternn)
all strings except those that match any pattern

Jun 022010

Ricoh Network Users Guide
Ricoh Software Users Guide
Ricoh Users Guide
Aficio SP C210SF.MacIntosh.Supplement-G1573701

Toner Cartriges

They should have an off white color not black. The black ones are the wrong type. Ricoh 402070 Type 140 Black Ricoh 402071 Type 140 Cyan Ricoh 402072 Type 140 Magenta Ricoh 402073 Type 140 Yellow Check wishlist.
May 142010

Adding MySql User Accounts

You can create MySQL accounts in two ways:

  • By using statements intended for creating accounts, such as CREATE USER or GRANT. These statements cause the server to make appropriate modifications to the grant tables.
  • By manipulating the MySQL grant tables directly with statements such as INSERT, UPDATE, or DELETE.

The preferred method is to use account-creation statements because they are more concise and less error-prone than manipulating the grant tables directly. CREATE USER and GRANT are described in Section 12.4.1, “Account Management Statements”.

Another option for creating accounts is to use one of several available third-party programs that offer capabilities for MySQL account administration. phpMyAdmin is one such program.

The following examples show how to use the mysql client program to set up new accounts. These examples assume that privileges have been set up according to the defaults described in Section 2.13.2, “Securing the Initial MySQL Accounts”. This means that to make changes, you must connect to the MySQL server as the MySQL root user, and the root account must have the INSERT privilege for the mysql database and the RELOAD administrative privilege.

As noted in the examples where appropriate, some of the statements will fail if the server’s SQL mode has been set to enable certain restrictions. In particular, strict mode (STRICT_TRANS_TABLES, STRICT_ALL_TABLES) and NO_AUTO_CREATE_USER will prevent the server from accepting some of the statements. Workarounds are indicated for these cases. For more information about SQL modes and their effect on grant table manipulation, see Section 5.1.7, “Server SQL Modes”, and Section, “GRANT Syntax”.

First, use the mysql program to connect to the server as the MySQL root user:

shell> mysql --user=root mysql

If you have assigned a password to the root account, you’ll also need to supply a --password or -p option, both for this mysql command and for those later in this section.

After connecting to the server as root, you can add new accounts. The following statements use GRANT to set up four new accounts:

mysql> CREATE USER 'monty'@'localhost' IDENTIFIED BY 'some_pass';
mysql> GRANT ALL PRIVILEGES ON *.* TO 'monty'@'localhost'
mysql> CREATE USER 'monty'@'%' IDENTIFIED BY 'some_pass';
mysql> GRANT ALL PRIVILEGES ON *.* TO 'monty'@'%'
mysql> CREATE USER 'admin'@'localhost';
mysql> GRANT RELOAD,PROCESS ON *.* TO 'admin'@'localhost';
mysql> CREATE USER 'dummy'@'localhost';

The accounts created by these statements have the following properties:

  • Two of the accounts have a user name of monty and a password of some_pass. Both accounts are superuser accounts with full privileges to do anything. The 'monty'@'localhost' account can be used only when connecting from the local host. The 'monty'@'%' account uses the '%' wildcard for the host part, so it can be used to connect from any host.It is necessary to have both accounts for monty to be able to connect from anywhere as monty. Without the localhost account, the anonymous-user account for localhost that is created by mysql_install_db would take precedence when monty connects from the local host. As a result, monty would be treated as an anonymous user. The reason for this is that the anonymous-user account has a more specific Host column value than the 'monty'@'%' account and thus comes earlier in the user table sort order. (user table sorting is discussed in Section 5.4.4, “Access Control, Stage 1: Connection Verification”.)
  • The 'admin'@'localhost' account has no password. This account can be used only by admin to connect from the local host. It is granted the RELOAD and PROCESS administrative privileges. These privileges allow the admin user to execute the mysqladmin reload, mysqladmin refresh, and mysqladmin flush-xxx commands, as well as mysqladmin processlist . No privileges are granted for accessing any databases. You could add such privileges later by issuing other GRANT statements.
  • The 'dummy'@'localhost' account has no password. This account can be used only to connect from the local host. No privileges are granted. It is assumed that you will grant specific privileges to the account later.

The statements that create accounts with no password will fail if the NO_AUTO_CREATE_USER SQL mode is enabled. To deal with this, use an IDENTIFIED BY clause that specifies a nonempty password.

To check the privileges for an account, use SHOW GRANTS:

mysql> SHOW GRANTS FOR 'admin'@'localhost';
| Grants for admin@localhost                          |
| GRANT RELOAD, PROCESS ON *.* TO 'admin'@'localhost' |

As an alternative to CREATE USER and GRANT, you can create the same accounts directly by issuing INSERT statements and then telling the server to reload the grant tables using FLUSH PRIVILEGES:

shell> mysql --user=root mysql
mysql> INSERT INTO user
    ->     VALUES('localhost','monty',PASSWORD('some_pass'),
    ->     'Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y');
mysql> INSERT INTO user
    ->     VALUES('%','monty',PASSWORD('some_pass'),
    ->     'Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y',
    ->     'Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y',
    ->     '','','','',0,0,0,0);
mysql> INSERT INTO user SET Host='localhost',User='admin',
    ->     Reload_priv='Y', Process_priv='Y';
mysql> INSERT INTO user (Host,User,Password)
    ->     VALUES('localhost','dummy','');

When you create accounts with INSERT, it is necessary to use FLUSH PRIVILEGES to tell the server to reload the grant tables. Otherwise, the changes go unnoticed until you restart the server. With CREATE USER, FLUSH PRIVILEGES is unnecessary.

The reason for using the PASSWORD() function with INSERT is to encrypt the password. The CREATE USER statement encrypts the password for you, so PASSWORD() is unnecessary.

The 'Y' values enable privileges for the accounts. Depending on your MySQL version, you may have to use a different number of 'Y' values in the first two INSERT statements. The INSERT statement for the admin account employs the more readable extended INSERT syntax using SET.

In the INSERT statement for the dummy account, only the Host, User, and Password columns in the user table row are assigned values. None of the privilege columns are set explicitly, so MySQL assigns them all the default value of 'N'. This is equivalent to what CREATE USER does.

If strict SQL mode is enabled, all columns that have no default value must have a value specified. In this case, INSERT statements must explicitly specify values for the ssl_cipher, x509_issuer, and x509_subject columns.

To set up a superuser account, it is necessary only to create a user table entry with the privilege columns set to 'Y'. The user table privileges are global, so no entries in any of the other grant tables are needed.

The next examples create three accounts and give them access to specific databases. Each of them has a user name of custom and password of obscure.

To create the accounts with CREATE USER and GRANT, use the following statements:

shell> mysql --user=root mysql
mysql> CREATE USER 'custom'@'localhost' IDENTIFIED BY 'obscure';
    ->     ON bankaccount.*
    ->     TO 'custom'@'localhost';
mysql> CREATE USER 'custom'@'' IDENTIFIED BY 'obscure';
    ->     ON expenses.*
    ->     TO 'custom'@'';
mysql> CREATE USER 'custom'@'server.domain' IDENTIFIED BY 'obscure';
    ->     ON customer.*
    ->     TO 'custom'@'server.domain';

The three accounts can be used as follows:

  • The first account can access the bankaccount database, but only from the local host.
  • The second account can access the expenses database, but only from the host
  • The third account can access the customer database, but only from the host server.domain.

To set up the custom accounts without GRANT, use INSERT statements as follows to modify the grant tables directly:

shell> mysql --user=root mysql
mysql> INSERT INTO user (Host,User,Password)
    ->     VALUES('localhost','custom',PASSWORD('obscure'));
mysql> INSERT INTO user (Host,User,Password)
    ->     VALUES('','custom',PASSWORD('obscure'));
mysql> INSERT INTO user (Host,User,Password)
    ->     VALUES('server.domain','custom',PASSWORD('obscure'));
mysql> INSERT INTO db
    ->     (Host,Db,User,Select_priv,Insert_priv,
    ->     Update_priv,Delete_priv,Create_priv,Drop_priv)
    ->     VALUES('localhost','bankaccount','custom',
    ->     'Y','Y','Y','Y','Y','Y');
mysql> INSERT INTO db
    ->     (Host,Db,User,Select_priv,Insert_priv,
    ->     Update_priv,Delete_priv,Create_priv,Drop_priv)
    ->     VALUES('','expenses','custom',
    ->     'Y','Y','Y','Y','Y','Y');
mysql> INSERT INTO db
    ->     (Host,Db,User,Select_priv,Insert_priv,
    ->     Update_priv,Delete_priv,Create_priv,Drop_priv)
    ->     VALUES('server.domain','customer','custom',
    ->     'Y','Y','Y','Y','Y','Y');

The first three INSERT statements add user table entries that allow the user custom to connect from the various hosts with the given password, but grant no global privileges (all privileges are set to the default value of 'N'). The next three INSERT statements add db table entries that grant privileges to custom for the bankaccount, expenses, and customer databases, but only when accessed from the proper hosts. As usual when you modify the grant tables directly, you must tell the server to reload them with FLUSH PRIVILEGES so that the privilege changes take effect.

To create a user who has access from all machines in a given domain (for example,, you can use the “%” wildcard character in the host part of the account name:

mysql> CREATE USER 'myname'@'' IDENTIFIED BY 'mypass';

To do the same thing by modifying the grant tables directly, do this:

mysql> INSERT INTO user (Host,User,Password,...)
    ->     VALUES('','myname',PASSWORD('mypass'),...);
Apr 062010


@echo off
REM Program Author: Robert Holland
REM Program Purpose: Display the username that is logged onto the computer.
REM Program Date: 20100406

if {“%1”} == {} goto :HelpMe
if {%1} == {^/^/} goto :HelpMe
if {%1} == {^/?} goto :HelpMe
if {%1} == {^/h} goto :HelpMe
if {%1} == {-h} goto :HelpMe

if NOT {%1} == {} (
psloggedon.exe -x \\%1)else goto HelpMe
goto :eof

@echo “Usage: loggedon targetcomputername”