Pattern Matching Tips

Grep Regular Expression

^

Denotes the beginning of a line

$

Denotes the end of a line

.

Matches any one characters

*

Matches 0 or more of the previous characters

.*

Matches any number or type of characters

[]

Matches on character for the one listed in the the Square brackets

[^]

Does not match any characters listed

<, >/

Denotes the beginning and end (respectively) of a word

So an example of a regular expression search would be

% grep "<[A-Za-z].*" file
This will search for any word which begins with a letter upper or lower case. 

Sed Replace Expression

To remove the comments from an apt sources.list file use:

sudo sed -i -e "s/# deb/deb/g" /etc/apt/sources.list

Regular Expression Operators

a?

matches 0 or 1 occurrence of *a*

'a' or empty string

a*

matches 0 or more occurrences of *a*

empty string or 'a', 'aa', 'aaa', etc

a+

matches 1 or more occurrences of *a*

'a', 'aa', 'aaa', etc

a|b

match *a* or *b*

'a' or 'b' -

.

match any single character

'a', 'q', 'l', '_', '+', etc

[woeirjsd]

match any of the named characters

'w', 'o', 'e', 'i', 'r', 'j', 's', 'd'

[1-9]

match any of the characters in the range

'1', '2', '3', '4', '5', '6', '7', '8', '9'

[^13579]

match any characters not named

even digits, or any other character

(ie)

group an expression (for use with other operators)

'ie'

^a

match an *a* at the beginning of a line

'a'

a$

match an *a* at the end of a line

'a'

Example:

/

[^?]

+

?

/

begin expression

any character other than '?'

more than one of those

a question mark

end expression

So the use of the in front of the ? makes it refer to an actual question mark.

Generate a java thread dump

Use Kill -3 PID, wherePID is the root of the process tree.

To obtain the root PID, perform a:

#ps -efHl | grep 'java' **. **

ps -efHl | grep 'java'

using a grep argument that is a string that will be found in the process stack that matches the server startup command. The first PID reported will be the root process, assuming that the ps command has not been piped to another routine.

The dump output should be saved to stderr for the process.

Note: Under Linux, each execute thread appears as a separate process under the Linux process stack. To use Kill -3 on Linux you supply must match PID of the main WebLogic execute thread, otherwise no thread dump will be produced

Execute the thread dump a few times over an interval to analyze trends.

http://www.me.umn.edu/~shivane/blogs/cafefeed/2004/06/of-thread-dumps-and-stack-traces.html

* How to do a thread dump on JBoss:

http://wiki.jboss.org/wiki/Wiki.jsp?page=GenerateAThreadDumpWithTheJMXConsole

* Look at garbage collection graphs (growing? high gc collection time?)

* Samurai: http://yusuke.homeip.net/samurai/?english

(Samurai is a tool to show thread dumps in graph form, highlighting the problem threads)

* To turn on verbose gc logging (if not available in console):

-verbose:gc or verbosegc

(Turn this on to help figure out memory leak or general memory problems. A lot of folks will just leave this on all the time - it's not a big overhead).

* JVM Tuning BEA 6 page: http://edocs.bea.com/wls/docs61/perform/JVMTuning.html

Automounting Windows Shares with CIFS

Create an /etc/auto.master file with your automount entries, for example:

/home /etc/auto.home --timeout=600 # entries in /etc/auto.home mount to /home

/log /etc/auto.log --timeout=600
/apps /etc/auto.apps --timeout=600

Create an /etc/smbmounts/servername auth file= o ns = "urn:schemas-microsoft-com:office:office" />

username=winusername

password=winpassword

domain=windomain

Create /etc/auto.home /etc/auto.log and /etc/auto.apps or whatever you like based upon your requirements using the format below:

CIFS format of auto.parentfoldername i.e. auto.home to access via /home/unixmountname

uid and gid are the unix id's you want the folders mounted as

file_mode is the permissions on files and dir_mode would be same mask for directory level

rsize and wsize are for tuning read and write block sizes

unixmountname -fstype=cifs,credentials=/etc/smbmounts/servername,uid=908,gid=908,file_mode=0774,rsize=32768 ://servername/sharename

for example for the /home /etc/auto.home entry you would create a file /etc/auto.home and put entry like the following for pvalentino's home folder which is hosted on server named filesrv1:

pvalentino -fstype=cifs,credentials=/etc/smbmounts/filesrv1,uid=908,gid=908,file_mode=0774,rsize=32768 ://filesrv1/pvalentino

restart autofs with:

/etc/init.d/autofs restart

or

service autofs restart

cd to your new directory

cd /home/pvalentino

check logs if you get errors.

Major differences in syntax between smbfs and cifs are:

smbfs uses fmask and cifs uses file_mode

smbfs credentials file uses username=DOMAINusername while cifs uses username=username and domain=domain entries

man mount.cifs for more details on mount options that are available

Basic OpenLDAP Configuration

The LDAP server itself (slapd) is controlled through a file called slapd.conf, which is usually stored in /etc/openldap. Two other LDAP configuration files, both called ldap.conf, control LDAP client operations. The /etc/ldap.conf file is used by LDAP’s Name Service Switch (NSS)interfaces, while /etc/openldap/ldap.conf specifies defaults for various LDAP client programs. For now, concentrate on slapd.conf.

The slapd.conf file is rather lengthy, but chances are your default configuration will work reasonably well once you’ve entered a few site-specific items. The first of these is to load an LDAP schema (a set of rules) for handling Linux account information. At the beginning of your default file, you’ll probably see a series of include directives. Be sure that your file has the following directives in the specified order:

include /etc/openldap/schema/core.schema

include /etc/openldap/schema/cosine.schema

include /etc/openldap/schema/nis.schema

The nis.schema file is the one that’s critical, but it relies on the preceding two. If your configuration loads other schema files, chances are they’ll do no harm, but they probably aren’t required for LDAP to function solely as a network authentication server.

Moving down a few lines, you may see a section that sets encryption options. If the following lines aren’t present, add them after the pidfile and args file options:

TLSCipherSuite

HIGHTLSCertificateFile /etc/openldap/ssl/slapd-cert.pem

TLSCertificateKeyFile /etc/openldap/ssl/slapd-key.pem

By default, LDAP doesn’t support encryption; these lines, in conjunction with procorgres described momentarily, enable encryption. This is an important feature for a network authentication server; you don’t want a user’s password to be sniffed as it’s exchanged! You can also set the security level and specify a default encoding for password storage:

security ssf=128 password-hash {SSHA}

Both of the values shown here are reasonable in most cases. Setting a lower ssf value (say, 112 or 56) disables the most robust encryption algorithms. The password-hash option accepts other values, but {SSHA} works well in most cases.The database option sets the type of backend database that LDAP uses:

database bdbdirectory /var/lib/ldap

The bdb value specifes Berkeley DB, but you can use other databases if you prefer; consult the OpenLDAP documentation for details. The directory option specifies the filesystem directory where the LDAP database files are stored. Be sure this directory exists and has mode 0700 (-rwx------) prior to running slapd. Several other database options may exist around or between these two lines. Chances are you won’t need to change them.

Several options set site-specific information on your network and its administration:

suffix "dc=pvalentino,dc=org"

rootdn "cn=oscar,dc=pvalentino,dc=org"

rootpw {SSHA}1gdwUg+YmJz7IlhpynZO/q6aiTB06Wqh

The suffix line sets the distinguished name (DN) for the LDAP directory. This is conventionally your DNS domain name split into parts (pvalentino.org in this example), but you can use other values if you prefer; the key is to be consistent in all your DN uses. The rootdn line specifies a DN that corresponds to a user who will administer the system. This should be the DN specified in the preceding suffix line with an additional CN code, which is conventionally Manager or admin. Finally, the rootpw line sets a password that’s used for administration (by the DN specified in the rootdn line). This password is stored in a hashed form. You can use the slappasswd command to generate the root password; type slappasswd and enter the

password twice. The program responds by displaying the hashed password, including an encoding value ({SSHA} in this example. Cut and paste this value, taking care to capture both ends of the string.

################################################################## database bdb suffix "dc=pvalentino,dc=org" rootdn "cn=oscar,dc=pvalentino,dc=org"

rootpw {SSHA}#EH(IOHEGOIOIEkjnda+elyr4mWeadfiahfadfe master

##################################################################

The final set of options in slapd.conf provide access control lists (ACLs) that relate to how users may access the directory:

access to attrs=userPassword by self write

by dn="uid=root,ou=People,dc=pvalentino,dc=org" write

by * auth

access to *

by * read

The first block of lines specifies rules for access to the userPassword attribute, which holds user passwords, as you might have

guessed. Specifically, users may write their own passwords (by self write), root may overwrite any password, and all users may

authenticate against passwords (by*auth). The second block of lines gives all users read access to the rest of the information in the directory (much as all users may read /etc/passwd). When specifying LDAP ACLs, order is important; earlier entries take precedence over later ones. Thus, the earlier ACL for userPassword, which doesn’t specify any read access, takes precedence over the later global read access ACL. This configuration prevents each user from reading his or her — or anyone’s — password. Once you’ve tweaked your default slapd.conf file, save it. You’re not quite ready to start the OpenLDAP server, though. Because you’ve configured LDAP to use encryption (via the three TLS* lines), you must first create keys and certificates. Creating Keys and Certificates TLS encryption, as used by OpenLDAP, is provided by the OpenSSL package, so you should install this software before proceeding. OpenSSL is designed to enable not just encryption, but also authentication of the server to its clients. You may optionally use a Certificate Authority (CA) to create an SSL key and certificate for your use; however, this option is most commonly employed by Web merchants and others who need to verify their identities to the public at large. For internal use, it’s faster and cheaper to generate your own keys and certificates. To do so, you’ll use the openssl command:

$ openssl req –x509 –days 365 –newkey rsa: –nodes –keyout slapd-key.pem –out slapd-cert.crt

For the most part, you needn’t be very concerned with the details of what these options mean, but you should type this command as root, exactly as specified, and in a directory to which you can write data. And although the certificate thus created officially expires in one year (-days 365), it will still be useful after that point for purposes of LDAP authentication. Once you type this command, the openssl program asks you for various pieces of identifying information, such as your location and your organization’s name. Answer in the way that seems reasonable, except for the Common Name(eg, YOUR name) prompt: Answer this question with the hostname or IP address of the LDAP server. The reason is that some clients (but not the Linux clients) are fussy about this field. If it doesn’t match the true hostname or IP address of the LDAP server, such clients might refuse the connection. When openssl is done, it writes two files: slapd-key.pem and slapd-cert.crt. These files hold a private key and a public

certificate, respectively. The slapd-key.pem file’s permissions are sensitive; you should be sure they’re set to 0600 (-rw-------) to ensure that the file isn’t stolen, enabling another computer to masquerade as your LDAP server. Once you’ve verified and, if necessary, changed the permissions on these files, you should move them to the directories (and names) specified by the TLSCertificateKeyFile and TLSCertificateFile parameters in slapd.conf.

Running the LDAP Server

Once you’ve modified your slapd.conf file and created your certificates and keys, you can launch the LDAP server itself. In most cases, you can do this via a SysV startup script:/etc/init.d/ldap start

The location and name of the startup script varies from one distribution to another, so you may need to hunt to find yours. To ensure that the server runs automatically whenever you start your system, you may need to check or modify your SysV startup script configuration. Typing chkconfig ldap on does the trick on many distributions. Unfortunately, some distributions’ LDAP server SysV startup scripts don’t include appropriate options to bind LDAP to all the ports needed for TLS-mediated operation. Typically, LDAP binds to port 389, which is usually adequate for use with Linux clients. Some other clients, though, may require LDAP to be bound to port 636 for secure LDAP (LDAPS) operation. To bind LDAP to other ports, you must pass the ports via the –h option when starting the server, as in –h ldap:// ldaps://. To accomplish this goal, you may need to edit a distribution-specific configuration file or the LDAP SysV startup script itself. Peruse your startup script to locate the call to the server. You may be able to find a variable, such as SLAPD_URLS, which you can modify to include the necessary information...

When using LDAP as an authentication server, the relevant LDIF information includes the data that's normally stored in /etc/passwd, /etc/shadow, and /etc/group, plus a few LDAP-specific fields. Listing One shows an example LDIF entry for a user, Paul Valentino, whose Linux

username is pvalentino. Listing One: A sample LDAP Data Interchange Format entry holding Linux account information

dn: uid=pvalentino,ou=People,dc=pvalentino,dc=org uid: pvalentino cn: Paul Valentino objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount userPassword: {crypt}KpP.s/mnFoEoI shadowLastChange: 12561 shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 780 gidNumber: 100 homeDirectory: /home/pvalentino gecos: Paul Valentino

For the most part, the names of the fields in Listing One ‘s LDIF entry should be self-explanatory to anybody who's already familiar with Linux accounts; however, a few fields require additional explanation. The first of these is the first line in Listing One: The entry begins with the distinguished name (DN) that applies to the account. This DN normally consists of the uid, ou, and one or more dc components. It should uniquely identify the account in question. The second field that requires explanation is the second line in Listing One. In LDAP parlance, a uid isn't a Linux user ID (UID); the LDAP uid is equivalent to the Linux username. The Linux UID must, of course, be stored in the directory, and in fact it appears later in Listing One, under the heading uidNumber. The user's password is specified in the LDIF entry in an encrypted form. You can use tools to enter an encrypted password, as described previously; however, as described shortly, there are easier ways to set passwords in most cases. You can use a few more fields, in addition to those shown in Listing One. These fields relate to shadow password and group features, such as shadowMin, shadowWarning, and memberUid. The tools described shortly create these fields, when necessary. Don't begin creating LDIF entries for your accounts just yet; tools to help automate the process exist, assuming you've got a working Linux account database. Understanding LDIF is helpful when you modify accounts or add fresh accounts, though. You may want to create a template LDIF entry, perhaps based on an existing account that you migrate, for use when adding new accounts.

Migrating an Existing Account Database

One useful approach to setting up a new LDAP server as an account maintenance system is to migrate an existing Linux account database. The tools to do this are available as scripts from http://www.padl.com/OSS/MigrationTools.html. The links at the bottom of that page retrieve a file called MigrationTools.tgz. To use the migration tools, you must first edit the migrate-common.ph file and change two lines that hold site-specific defaults. The variables in question are $DEFAULT_MAIL_DOMAIN and $DEFAULT_BASE. They must be set to hold your site's DNS domain name and your directory's base:

$DEFAULT_MAIL_DOMAIN = "pvalentino.org"; $DEFAULT_BASE = "dc=pvalentino,dc=org";

This example sets defaults that are appropriate for a fictitious pvalentino.org domain. If you're using LDAP for more than just login authentication, you might want to make similar adjustments to additional variables, such as $DEFAULT_MAIL_HOST (which points to your site's mail server); however, such changes are unnecessary if you're only using LDAP for network account authentication. Once you've modified the migrate-common.ph file, you can use two scripts to create LDIF files holding your user and group information:

$ sudo ./migrate_passwd.pl /etc/passwd passwd.ldif $ sudo ./migrate_group.pl /etc/group group.ldif

You must run these commands as root, because other users won't be able to read the shadow password file, which is necessary for successful creation of the LDIF files. Note that the migrate_passwd.pl script reads your shadow password file, despite the fact that you don't explicitly refer to it on the command line.The result of typing these two commands is, as you might expect, two LDIF files: passwd.ldif and group.ldif. Unfortunately, these files aren't quite complete. You must add information for the top-level DN to both files.You must add six lines to the start of the passwd.ldif file:

dn: dc=pvalentino,dc=org objectClass: domain dc: pvalentino

dn: ou=People,dc=pvalentino,dc=org objectClass: organizationalUnit ou: People

Of course, you should modify the domain information to match your own domain. You need only add three lines to the top of the group.ldif file:

dn: ou=Group,dc=pvalentino,dc=org objectClass: organizationalUnit ou: Group

Once again, change the DN to match your own local network. In addition to making these changes, you may want to peruse the files and remove entries for accounts and groups that you don't want the LDAP server to manage. For instance, your template Linux account files are likely to include accounts for users such as daemon, lp, shutdown, and other system accounts. Adding such accounts to LDAP increases clutter in your directory and could conceivably cause problems if the same username is associated with different Linux UIDs (LDAP uidNumber fields) in a client's local account database and in LDAP, or if a single UID number maps to different usernames. vLikewise, you might want to set different rootvpasswords on each client, in which case you should remove the entry for root. Before proceeding further, you should temporarily shut down your LDAP server, if it's running. Use your SysV startup scripts or other methods to do so. Once you've made these changes, you can add the LDIF files to LDAP by using the slapadd utility:

$ sudo slapadd –v –l passwd.ldif $ sudo slapadd –v –l group.ldif

Once you've added these entries to your LDAP directory, you can restart the LDAP server. In principle, you could use the ldapadd utility instead of slapadd; however, ldapadd requires you to have configured LDAP for account maintenance, as described shortly.

Adding Accounts

Chances are that sooner or later you'll need to modify your LDAP account directory after you've migrated an existing Linux account database to LDAP. Naturally, LDAP provides tools to do so; you can add new accounts, modify existing accounts, or delete existing accounts. You can also change passwords, although the client configuration described ahead provides an easier way to perform this task. To create a new account, you must first create an LDIF file that specifies the account. One way to do this is to extract a single account's information from the file with all your system's account data that you created earlier. You can then modify this information in a text editor. The result should resemble Listing One, although of course the details will differ. Be sure that the dn, uid, and uidNumber entries for your new account are unique. (Once your system is configured to use LDAP for authentication, as described ahead, you'll be able to type getent passwd to obtain a complete list of accounts to help avoid LDAP uid and uidNumber collisions.) If you want to set a password at account-creation time, you can use slappasswd to generate an encrypted value, as described previously in reference to the LDAP administrative password. Before proceeding further, you should temporarily shut down your LDAP server. You can then add your new account to the LDAP account directory by using slapadd, just as you did when you created the initial account directory:

$ sudo slapadd –v -l acct.ldif

You must run this command as root on the LDAP server computer. Additional account management tools require that the LDAP server be running. These commands can be run from the LDAP server computer or from other systems.

Managing Accounts Remotely

Before you can use LDAP for most account maintenance tasks, you must configure at least one system to connect to the LDAP server to perform these tasks. The LDAP server must also be running, as described previously. To configure the LDAP account-maintenance tools, you should edit the /etc/openldap/ldap.conf file. (Don't confuse this file with /etc/ldap.conf, which is used by other LDAP utilities.) You should set the BASE, URI, and TLS_CACERT options in this file:

BASE dc=pvalentino,dc=org URI ldaps://ldap.pvalentino.org TLS_CACERT /etc/openldap/ssl/certs/slapd-cert.crt

You should modify these entries as appropriate for your system. The BASE option points to the root of your LDAP directory. The URI option specifies the hostname on which the LDAP server is running, preceded by ldaps://. Note that you can perform account maintenance tasks on a computer other than the LDAP server itself. Finally, the TLS_CACERT option points to the certificate file you generated previously. If you want to perform account maintenance tasks on a computer other than the LDAP server system, you must copy the public certificate file to the computer that's to serve as an account maintenance platform. Once you've taken care of these basics, you can use the ldapadd, ldapmodify, ldappasswd, and ldapdelete utilities to add new accounts, modify existing accounts, change the passwords of existing accounts, and delete existing accounts, respectively. The ldapadd utility's function overlaps with that of slapadd, except that you may run ldapadd as any user on any computer that's configured as just described; slapadd must be run on the LDAP server system. The ldapadd command is also a bit more complex than is the slapadd command:

ldapadd –D cn=manager,dc=pvalentino,dc=org –W –f acct.ldif

You must specify the DN for the directory's administrator, as you specified it when configuring LDAP. The program prompts you for a password; you should enter the one you specified (in encrypted form) in the LDAP configuration file on the server, as described last month. The ldapmodify command is another name for ldapadd, but when called as ldapmodify, the program enables you to modify an existing entry rather than add a new one. You can create an LDIF file and its entries will replace conflicting entries in the existing directory. Entries that you omit from the LDIF file won't be changed. You can use this technique to alter a user's home directory, login shell, password, or other account features.

One common administrative task is altering user passwords. Instead of using ldapmodify and an LDIF file to do this job, you can change a password using the ldappasswd command:

$ sudo ldappasswd –D cn=manager,dc=pvalentino,dc=org –S -W uid=pvalentino,ou=People,dc=pvalentino,dc=org

Before prompting for your administrative password, the program asks for you to enter the new password twice. Because this tool requires the LDAP administrative password, it can't be used by ordinary users. You can, however, configure Linux to have its normal passwd utility update users' LDAP passwords. This topic is covered ahead. To delete an existing account entry, you can use the ldapdelete command:

$ sudo ldapdelete –D cn=manager,dc=pvalentino,dc=org –W uid=pvalentino,ou=People,dc=pvalentino,dc=org

Again, you're be prompted for your password. If all goes well, LDAP will delete the specified account (for pvalentino in the People OU, in

this case). You can use the ldapadd, ldapmodify, and ldapdelete utilities to add, modify, or delete the groups managed by LDAP. The procorgres are identical to those for managing accounts; you just need a different LDIF file (modeled after entries in group.ldif) and a different DN to uniquely identify a group rather than an account.

The Roles of NSS and PAM

Most people give little thought to the details of how Linux accounts are structured. In fact, there are several characteristics of accounts, such as usernames, passwords, home directories, default shells, and so on. These features are managed by two Linux tools: PAM is a security tool; it tells login tools, such as the text-mode login process or the GUI GNOME Display Manager (GDM) or KDE Display Manager (KDM), that the password a user types is (or is not) correct for the specified username. PAM also handles some additional tasks, such as changing passwords when a user runs the passwd utility. NSS handles less sensitive account data, such as the path to a user's home directory, his or her default shell, and so on. If you configure PAM but not NSS to use LDAP, only users who have local account data stored in /etc/passwd and /etc/shadow will be able to log in. These files could lack passwords, but they'd have to host the normal NSS data. If you configure NSS but not PAM to use LDAP, then Linux will believe it has accounts for the users defined on the LDAP server, but those users won't be able to log in. Thus, to use an LDAP server for authentication, you must normally reconfigure both PAM and NSS to use LDAP. Either alone could be useful in some limited circumstances, but in most cases you must configure both to use LDAP.

Setting Basic LDAP Client Options

Before proceeding with NSS and PAM configuration, you must set a few client-wide LDAP options. To do so, you should first ensure that the PAM and NSS LDAP libraries are installed on your client computer. These tools are usually stored in packages called pam_ldap and nss_ldap, although some distributions use other names, such as libpam-ldap and libnss-ldap. Some distributions combine both packages into one — nss_ldap in the case of Fedora Core 6, for instance. In most cases, the LDAP client tools for NSS and PAM both rely on the /etc/ldap.conf file. Debian and its derivative distributions use two files, /etc/nss_ldap.conf and /etc/pam_ldap.conf. If your distribution uses two files, you must make similar changes to both. Be sure not to confuse this file with the /etc/openldap/ldap.conf, which is the configuration file for the LDAP tools described previously. To proceed, load your /etc/ldap.conf file into an editor and change the host and base lines:

host 192.168.1.3 base dc=pvalentino,dc=org

The host line specifies the LDAP server's IP address or hostname, so modify it to suit your network's neeeds. The base line points to the base directory used by your LDAP account directory. As described two months ago, this is often related to your domain name, but it need not be. You may want to peruse additional options in the /etc/ldap.conf file. Many default files include commented-out options related to port numbers, encryption, and other features. In a high-security environment, you may want to enable some of these options. Doing so can improve security, but these features can be difficult to debug.

Setting NSS Options

Telling NSS to use LDAP is fairly straightforward. The main NSS configuration file is /etc/nsswitch.conf, and you must edit three

lines to have NSS use LDAP. These lines begin with the words passwd, shadow, and group, and you should add the string ldap to each of these lines:

passwd: files ldap shadow: files ldap group: files ldap

In practice, NSS uses each of the named subsystems in the order in which they're listed for the duties specified by the leading keyword. You may have noticed that each of these lines begins with the name of a file that's used in Linux account management: /etc/passwd, /etc/shadow, and /etc/group. This is because NSS ordinarily accesses these files (hence the files keyword). By adding ldap to the end of the line, you direct NSS to use the local files first and then to call on LDAP. Thus, when reconfigured in this way, your system will include all the locally-defined accounts and groups, plus whatever accounts or groups are defined in the LDAP directory. It's possible that your configuration will include other keywords, in addition to or instead of the files keyword that's common to the lines in this example. For instance, many systems use compat rather than files. If so, the safest approach is usually to add ldap to the end of each line.

Setting PAM Options

PAM is a more complex subsystem than NSS to configure as an LDAP authentication client. As noted earlier, PAM stands for Pluggable Authentication Modules. The modules referred to in the name are pieces of code, similar to libraries or kernel modules, that extend PAM to handle new authentication methods. The PAM LDAP package you installed earlier provides an LDAP module for PAM; this module" talks" to the LDAP server, providing an interface between the LDAP server and the local computer's authentication system. The main PAM configuration file is /etc/pam.conf; however, all common Linux distributions place the bulk of the PAM configuration in files within the /etc/pam.d directory. Each file in this directory controls one authentication tool. For instance, /etc/pam.d/login controls the login process, /etc/pam.d/gdm controls the GDM GUI login tool, and /etc/pam.d/su controls the su command's authentication. In theory, to configure PAM to use LDAP, you must modify the files for each subsystem that should use LDAP. Precisely which files and subsystems this should be can vary greatly from one computer to another; for instance, you might need to modify files for a Post Office Protocol (POP) email server on one computer, but for GDM on another computer. Fortunately, many Linux distributions provide a shortcut:

/etc/pam.d/system-auth

Not all distributions use this file, but if yours does, you can modify just this one file rather than modifying all the relevant authentication programs' files. Whether you need to modify the system-auth file or multiple files, though, the procedure is similar. PAM authentication files consist of stacks, which are sets of external modules that provide authentication services. These stacks are broken into four management groups: auth, account, password, and session. Each management group's stack defines the rules that PAM uses to perform a specific action, such as authenticate a user (auth) or manage a login session (session). A typical authentication stack resembles Listing One, which is based on a Gentoo PAM stack. (Some lines have been broken for publication.)

Listing One: A typical PAM authentication stack

#%PAM-1.0

auth required pam_env.so auth sufficient pam_unix.so likeauth nullok auth required pam_deny.so

account required pam_unix.so

password required pam_cracklib.so retry=3 password sufficient pam_unix.so nullok md5 shadow use_authtok password required pam_deny.so

session required pam_limits.so session required pam_unix.so

To add LDAP authentication to the mix, you must add a reference to the LDAP authentication module (pam_ldap.so) to each of the management groups. To do so, though, you must first understand a bit about how PAM processes its stacks. When it's called upon to perform an action, such as authenticate a user or change a password, PAM calls each of the modules (in the third column of Listing One) for the associated management group in turn. Ultimately, the action will succeed or fail, and which happens depends on the successful completion of each module in conjunction with the control flag in the second column of Listing One. Of most importance are the requisite, required, and sufficient flags: A requisite flag means that the module must succeed if the stack is to succeed. If the module fails, stack execution terminates immediately. A required flag is much like a requisite flag, but if the module fails, execution continues until the end. A sufficient flag causes stack execution to immediately terminate with a successful outcome if the associated module succeeds, provided no previous required module failed. If a sufficient module fails, the stack as a whole could still succeed, if other modules cause it to succeed — that is, a module failure causes the stack to work as if the sufficient module has not been present in the stack. The default stacks provided with most Linux distributions rely heavily on requisite or required flags, with an occasional sufficient flag thrown in; Listing One is a typical example. To add LDAP authentication while keeping local authentication working, you must add references to the pam_ldap.so module as sufficient. You must also usually change some of the requisite or required modules to be sufficient. The result might resemble Listing Two.

Listing Two: A PAM authentication stack that uses LDAP

#%PAM-1.0

auth required pam_env.so auth sufficient pam_unix.so likeauth nullok auth sufficient pam_ldap.so try_first_pass auth required pam_deny.so

account sufficient pam_unix.so account sufficient pam_ldap.so

password required pam_cracklib.so retry=3 password sufficient pam_unix.so nullok md5 shadow use_authtok password sufficient pam_ldap.so use_authtok debug password required pam_deny.so

session required pam_limits.so session sufficient pam_unix.so session sufficient pam_ldap.so use_first_pass

session required pam_mkhomedir.so skel=/etc/skel umask=0027 In this example, Listing One uses the pam_unix.so module to perform the key tasks for each of the four management groups; however, some distributions use other modules instead of pam_unix.so, so you may need to do some research on your distribution's PAM defaults. To add LDAP to the mix, you add its line after the pam_unix.so line and, if pam_unix.so is set to be requisite or required, change it to sufficient. Alternatively, you could add pam_ldap.so to the stack before the requisite or required module; pam_ldap.so, if successful, will then bypass the requisite or required module. You may also need to add a reference to pam_deny.so to the auth and password stacks; if you don't, the stack may incorrectly indicate success even when an incorrect password is entered. (You may need to test both ways, as described shortly.)The pam_ldap.so lines in Listing Two include parameters that vary from one management group to another. These parameters tweak the module's behavior. For instance, the try_first_pass and use_first_pass options tell the module to try the password collected on behalf of the first authentication tool. Without these options, users may be prompted for their passwords twice when they have only LDAP accounts. Listing Two's final line is a new one that's unrelated to LDAP, but that's very useful for network logins: The pam_mkhomedir.so module automatically creates a new home directory for a user if one doesn't already exist. You can call this module as part of the session management group, using options as shown in Listing Two to specify template files and permissions. Of course, this tool is most useful on workstations or computers that should have home directories. You might not need it for all systems. Remember to make changes either to the /etc/pam.d/system-auth file or to the configuration files for all of the authentication tools you want to use LDAP. Note that if you modify individual configuration files, not all files use all of the management groups shown in Listing One and Listing Two, so you might not need to make all of the changes shown in Listing Two.

Testing Proper Functioning

Once you've made your changes, you should test them. Try using each authentication tool to log in using several different types of

accounts and procedures:

Use a real local account with a correct password

Use a real local account with an incorrect password

Use a real LDAP account with a correct password

Use a real LDAP account with an incorrect password

Use an account that exists in neither the local account database nor LDAP You should see the correct login behavior in each of these cases. If you see authentication failures when you type the correct password or, worse in some ways, authentication successes when you use an incorrect password or a non-existent account, you should review your configuration. Unfortunately, there's little standardization between Linux distributions concerning their default PAM configurations, so the changes that work for one distribution might not work for another. You may need to experiment or look for distribution-specific documentation to help fill in the gaps. Be sure to test every authentication tool, or at least every one you've altered to use LDAP. The passwd utility deserves special mention: If you change the /etc/pam.d/passwd configuration file, or if it uses the system-auth stack, users who use the passwd command to change their passwords should change their passwords in the local database, in the LDAP directory, or in both, depending on precisely how you've configured PAM. Check both the local database and LDAP to be sure that the changes have been made as you expect

Changing LANG support on Redhat

vi /etc/sysconfig/i18n

LANG="en_US" SUPPORTED="en_US:en" SYSFONT="latarcyrheb-sun16"

And set values according to your requirements, typically one of the following settings in US

LANG

en_US.UTF-8

en_US

SUPPORTED

en_US.UTF-8:en_US:en

en_US:en

NTP Setup on RedHat

Create file /etc/ntp.conf with following:

restrict <time server ip> mask 255.255.255.255 server <time server ip> driftfile /var/lib/ntp/drift broadcastdelay 0.008 authenticate yes keys /etc/ntp/keys

Then run:

chkconfig ntpd on

service ntpd start

Verify timezone:

Look in /usr/share/zoneinfo for your timezone and link it to /etc/localtime i.e.

for America Chicago Central Time:

ln -s /usr/share/zoneinfo/America/Chicago /etc/localtime

Redhat CIFS mounting with FSTAB and credentials file

As the root user:

Create files in /etc/smbmounts for each set of credentials you need to mount various windows fileserver shares

i.e. server1,server2, and server3 or domain1,domain2, and domain3

or hide these files by naming .server1 .....

Example file serverX should contain the following with no whitespaces

username=windowsusername

password=windowspassword

domain=windowsdomain

chmod 600 on the serverX or domainX or whatever name you chose for them

Edit /etc/fstab and add the following to the end:

# For a password protected rw share

//servername/sharename /mount/sharename cifs credentials=/etc/smbmounts/.server1,iocharset=utf8,file_mode=0777,dir_mode=0777 1 3

# For a read only share

//servername/sharename /media/sharename cifs guest,iocharset=utf8 1 3

Migrating Users and Groups from 1 Linux to another:

On source server:

export UGIDLIMIT=500

mkdir /root/move

awk -v LIMIT=$UGIDLIMIT -F: '($3>=LIMIT) && ($3!=65534)' /etc/passwd > /root/move/passwd.mig

cat /root/move/passwd.mig

awk -v LIMIT=$UGIDLIMIT -F: '($3>=LIMIT) && ($3!=65534)' /etc/group > /root/move/group.mig

cat /root/move/group.mig

awk -v LIMIT=$UGIDLIMIT -F: '($3>=LIMIT) && ($3!=65534) {print $1}' /etc/passwd tee - egrep -f - /etc/shadow > /root/move/shadow.mig

cat /root/move/shadow.mig

use scp or sftp to move backup *.mig and *.gz files over to the new server /tmp directory then delete the *.gz files from the source server to free up space

On the target server:

cd /tmp cat passwd.mig >> /etc/passwd

vi /etc/passwd # to verify things look correct vi passwd.img

cat group.mig >> /etc/group

vi /etc/group

cat shadow.mig >> /etc/shadow vi /etc/shadow

cd / tar -zxvf /tmp/home.tar.gz rm -rf /tmp/home.tar.gz

cd / tar -zxvf /tmp/mail.tar.gz rm -rf /tmp/mail.tar.gz

reboot the server once all files have been verified and are correctly formatt

My JBoss Deploy Scripts

CVS structure:

/usr/local/cvsroot/applications/<project>/database

/usr/local/cvsroot/applications/<project>/documentation

/usr/local/cvsroot/applications/<project>/inactive

/usr/local/cvsroot/applications/<project>/jboss

/usr/local/cvsroot/applications/<project>/pgs

Prerequisites:

JDK 1.5.0_11 in /apps/java/ & ln -s /apps/java/jdk1.5.0_11 default

JBoss 4.2.0 GA in /apps/jboss & ln -s /apps/jboss/jboss4.2.0... default

Redhat 4 AS

Anthill 3.2.1

/apps/anthill/anthill3/agent

/apps/java/

/apps/jboss/default/server/<instance>

/apps/jboss/default/server/<instance>/deploy

/apps/jboss/default/server/<instance>/jboss-config

/apps/inet/server/<instance>

/apps/inet/server/conf

/apps/inet/deploy/scripts

/log/<instance>

/data/<instance>

chown on all directories to a consistent userid

Install Anthill agent

  1. untar anthill3-3.2.1.tar.gz into a convenient, temporary directory.
  2. Run the following commands
    1. cd anthill3-install

    2. export JAVA_HOME= /apps/java/default

    3. /bin/bash install-agent.sh

Directory where AnthillPro3 agent should be installed:

/apps/anthill/anthill3/agent

The home directory of the JDK:

/apps/java/default

The external IP address where the agent can be reached:

This is the IP address for the server where you are installing the agent.

The port where the agent can be reached:

Use default of 4568

The IP address on which the Anthill3 Server is listening

The anthill server's IP address

The port on which the Anthill3 Server is listening for Agents

Use default of 4567

Enter the name for this Agent.:

Use the hostname of the server where you are installing the agent

Anthill will cache all the deployment files in ~userid/.codestation/cache. This will quickly use up disk space.

To turn the caching off create a properties file using the following command. The anthill client must be stopped and restarted before this will take effect.

echo codestation.noCache=true > ~/.codestation/codestation.properties

To install base JBoss

  1. untar JBoss into /apps/jboss/jboss-4.2.0
  2. Make a symbolic link to into /apps/jboss/default with ln -s jboss-4.2.0 default

Setup properties file for each instance of JBoss

In /apps/inet/server/<instance>/

Add files named <instance>.properties that contain:

# Set ip and ports here

hostIp="x.x.x.x"

jvmDebugPort="8787"

jmxRemotePort="1999"

Then in /apps/inet/server/<instance>/deploy/ add your database and ldap config files:

oracle-ds.xml

oracleJms-ds.xml

login-config.xml # LDAP

These files will vary depending upon your environment

#runDeployInet2JBoss.sh in cvs under pgs/scripts folder

#!/bin/bash

# hack for anthill3 ??? /bin/chmod +x *.sh */*.sh 2>/dev/null >/dev/null

LINUX_SERVER=$(hostname)

# for now this only handles the "inet" server # this will be expanded to be able to deploy multiple iinet servers per linux server. # if [[ $# = 1 ]] then inet_SERVER="$1" else inet_SERVER="inet" fi

inet_SERVER_DIR="/apps/jboss/default/server/${inet_SERVER}"

JBOSS_HOME="/apps/jboss/default" inet_DIR="/apps/inet"

CONFDIR=${inet_DIR}

STOPCMD="${inet_SERVER_DIR}/bin/stopJBoss" STARTCMD="${inet_SERVER_DIR}/bin/startJBoss" /bin/chmod +x ${STOPCMD} /bin/chmod +x ${STARTCMD}

###################### # get path to deploy scripts ###################### WD=$(/bin/pwd) case "${0}" in /*) cmdDir=$(dirname "$0") ;; *) cmdDir=$(dirname "${WD}/$0") ;; esac

cd $cmdDir deployDir=$(/bin/pwd) cd ${WD}

###################### # find zip and ear ###################### conf=$(/bin/ls *.zip) ear=$(/bin/ls *.ear)

dir=$(pwd) instconf="$dir/$conf" instear="$dir/$ear"

if [[ ! -d ${inet_DIR}/uploads ]] then mkdir ${inet_DIR}/uploads fi conf="${inet_DIR}/uploads/$conf" ear="${inet_DIR}/uploads/$ear"

# copy ear to Upload dir in case manual deploymnet is needed in the future # a cheat, mkdir directory but ignore error if it is already there mkdir ${inet_DIR}/uploads 2>/dev/null cp $instconf $conf cp $instear $ear

###################### # deploy conf zip ######################

echo "Replace config" cd ${CONFDIR} DATE=$(date "+%H%M-%d%m%y") mv conf conf.${DATE} 2>/dev/null /usr/bin/unzip -q ${conf} r=$? if (( $r != 0 )) then echo "Problems unzipping ${config} into ${CONFDIR}" exit -1 fi

############################################### # now make all the required directories under /data/<server>/ ############################################### ${deployDir}/killJboss.sh ${inet_SERVER}

# the liost of files is under the conf directory list=${CONFDIR}/conf/batch/list-of-data-directories

# the data dir is server specific datadir=/data/inet/${SERVER}

# run the script ${deployDir}/mkDataDir.sh $datadir $list r=$? if (( $r != 0 )) then echo "Problems creating data directories" exit -1 fi

# run stopJboss ${deployDir}/isUp.sh $LINUX_SERVER 0 state=$? if(( $state == 0 )) then echo "Stopping JBoss" ${STOPCMD} 2>/dev/null >/dev/null fi

# remove old ear echo "Replace old ear with new" /bin/rm ${inet_SERVER_DIR}/deploy/*.ear 2>/dev/null # cp ear into place cp ${ear} ${inet_SERVER_DIR}/deploy

# start Jboss echo "Start JBoss" nohup ${STARTCMD} >/dev/null 2>/dev/null &

${deployDir}/isUp.sh $LINUX_SERVER 30 state=$? if(( $state == 0 )) then echo "inet up and deployed" exit 0

else echo "Server failed tp startup" exit -1 fi

#installInetServer.sh

#!/bin/bash

#

# This looks for inet server definition files eg inet.properities

# it will install on an inet server for each definition it finds

#

# hack for anthill3 ???

/bin/chmod +x scripts/*.sh 2>/dev/null >/dev/null

inetServerDir="/apps/inet/server"

if [[ ! -d ${inetServerDir} ]]

then

echo "No inet directory: ${inetServerDir}"

exit -1

fi

SERVERS=$(cd ${inetServerDir}; ls */*.properties sed -e "s//.*.properties//")

echo $SERVERS

for server in $SERVERS

do

echo "Deploy server: $server"

echo runDeployJBoss.sh $server

/bin/bash scripts/runDeployJBoss.sh $server

ret=$?

if (( $ret != 0 ))

then

exit $ret

fi

echo runDeployInet2JBoss.sh $server

/bin/bash scripts/runDeployInet2JBoss.sh $server

ret=$?

if (( $ret != 0 ))

then

exit $ret

fi

echo ""

done

#runDeployJBoss.sh

#!/bin/bash

JBOSS_HOME="/apps/jboss/default"

# If called directly this will install the inet server

# if told what server to install it will install the server defined.

#

if [[ $# = 1 ]]

then

INET_SERVER="$1"

else

INET_SERVER="inet"

fi

INET_SERVER_DIR="/apps/jboss/default/server/${INET_SERVER}"

####################################################

#

# LIST of JBoss Config files that are copied from the old version to the new

#

##################################################

# hack for anthill3 ???

/bin/chmod +x *.sh */*.sh 2>/dev/null >/dev/null

LINUX_SERVER=$(hostname)

INET_DIR="/apps/inet"

STOPCMD="${INET_SERVER_DIR}/bin/stopJBoss"

STARTCMD="${INET_SERVER_DIR}/bin/startJBoss"

ISUP="${INET_SERVER_DIR}/bin/isUp.sh"

STARTUP="${INET_SERVER_DIR}/bin/inet"

CHKVERSION="${INET_SERVER_DIR}/bin/checkJBossVersion"

/bin/chmod +x ${STOPCMD}

/bin/chmod +x ${STARTCMD}

/bin/chmod +x ${ISUP}

/bin/chmod +x ${STARTUP}

######################

# get path to deploy scripts

######################

WD=$(/bin/pwd)

case "${0}" in

/*)

cmdDir=$(dirname "$0")

;;

*)

cmdDir=$(dirname "${WD}/$0")

;;

esac

cd $cmdDir

deployDir=$(/bin/pwd)

# get JBOSDIR

cd ${JBOSS_HOME}/..

JBOSSDIR=$(/bin/pwd)

cd ${WD}

######################

# find zip and ear

######################

tarfile=$(/bin/ls jboss*.tgz)

if [[ "a_${tarfile}" = "a" ]]

then

echo "Could not find jboss tar file"

exit -1

fi

# Name of new JBoss

jbossVersion=$(echo $tarfile sed -e "s/.tgz//")

dir=$(pwd)

tarfile="$dir/$tarfile"

######################

# stop server

######################

# run stopJboss

${deployDir}/isUp.sh $LINUX_SERVER 0

state=$?

if(( $state == 0 ))

then

echo "Stopping JBoss"

${STOPCMD} 2>/dev/null >/dev/null

# we need to wait a bit to be sure Jboss is down

sleep 30

# the server can get into a state where it won't die nicely

# this will kill it real good.

${deployDir}/killJboss.sh ${INET_SERVER}

fi

######################

# move old jboss

######################

echo "Installing $tarfile into $INET_SERVER_DIR"

# check if already installed

cd ${INET_SERVER_DIR}/..

if [[ -d ${INET_SERVER} ]]

then

suffix=$(date "+%H%M%S-%d%m%y")

mv ${INET_SERVER} "${INET_SERVER}_${suffix}"

fi

/bin/mkdir ${INET_SERVER_DIR}

cd ${INET_SERVER_DIR}

tar -xzf $tarfile

r=$?

if (( $r != 0 ))

then

echo "Problems untarring $tarfile into $INET_SERVER_DIR"

exit -1

fi

##################################################

# Clean out any oracle or informix setup files

##################################################

/bin/rm ${INET_SERVER_DIR}/deploy/oracle*ds.xml 2>/dev/null

/bin/rm ${INET_SERVER_DIR}/deploy/informix*ds.xml 2>/dev/null

###############################################

# we create a startup script named after the server.

###############################################

mv ${STARTUP} ${INET_SERVER_DIR}/bin/${INET_SERVER}.sh

/bin/chmod +x ${INET_SERVER_DIR}/bin/${INET_SERVER}.sh

# just to be sure CVS can mess things up.

###############################################

# now compare the verions of JBoss to be sure they are the same

###############################################

# just to be sure CVS can mess things up.

/bin/chmod +x ${CHKVERSION}

${CHKVERSION}

r=$?

if (( $r != 0 ))

then

echo "Version mismatch. stopping install"

exit -1

fi

exit 0

checkJBossVersion.sh

#!/bin/bash ###

JBOSS_SERVER_VERSION="4.2.0.GA" JAVA_VERSION="1.5.0_11"

export JAVA_HOME="/apps/java/default" export JBOSS_HOME="/apps/jboss/default" export PATH=${JAVA_HOME}/bin:${PATH} JAVA=${JAVA_HOME}/bin/java

# make the JBOSS_HOME the real path not a slimebolic link. WD=$(/bin/pwd) cd ${JBOSS_HOME} jb=$(/bin/pwd) export JBOSS_HOME="$jb" cd $WD

CP="${JBOSS_HOME}/bin/run.jar" CLASSPATH="$CP" export CLASSPATH

PROGNAME=`basename $0`

# trick to find which server we are running WD=$(/bin/pwd)

case "${0}" in /*) cmdDir=$(dirname "$0") ;; *) cmdDir=$(dirname "${WD}/$0") ;; esac

cd $cmdDir

cd ${JBOSS_HOME}/bin jbVersion=$(${JAVA} -classpath $CP org.jboss.Main --version head -1 awk '{print $2}')

if [ "${jbVersion}" != "${JBOSS_SERVER_VERSION}" ] then echo "JBoss server has wrong version: ${jbVersion} should be: ${JBOSS_SERVER_VERSION}" echo "see $0" exit -255 else echo "JBoss version is correct: ${JBOSS_SERVER_VERSION}" fi

jVersion=$(${JAVA} -version 2>&1 head -1 awk '{print $3}' sed -e "s/"//g") if [ "${jVersion}" != "${JAVA_VERSION}" ] then echo "Java is wrong version: ${jVersion} should be: ${JAVA_VERSION}" echo "see $0" exit -255 else echo "Java version is correct: ${JAVA_VERSION}" fi

exit 0

#startJBoss

#!/bin/sh ### ====================================================================== ### ## ## ## JBoss Bootstrap Script ## ## ## ### ====================================================================== ###

export JAVA_HOME="/apps/java/default" export JBOSS_HOME="/apps/jboss/default" export PATH=${JAVA_HOME}/bin:${PATH} JAVA=${JAVA_HOME}/bin/java

# make the JBOSS_HOME the real path not a slimebolic link. WD=$(/bin/pwd) cd ${JBOSS_HOME} jb=$(/bin/pwd) export JBOSS_HOME="$jb" cd $WD

CP="${JAVA_HOME}/lib/tools.jar" CLASSPATH="$CP" export CLASSPATH

PROGNAME=`basename $0` whoiam=$(/usr/bin/id --user --name) if [[ "$whoiam" != "<userid>" ]] then echo "$PROGNAME: This script must be run as <userid>." exit -1 fi

# trick to find which server we are running WD=$(/bin/pwd)

case "${0}" in /*) cmdDir=$(dirname "$0") ;; *) cmdDir=$(dirname "${WD}/$0") ;; esac

cd $cmdDir wrkDir=$(/bin/pwd) SERVER=$(echo $wrkDir sed -e "s^${JBOSS_HOME}/server/^^" sed -e "s^/.*^^") SERVERDIR="${JBOSS_HOME}/server/${SERVER}" pid=${SERVERDIR}/${SERVER}.pid LOGFILE="${SERVERDIR}/log/${SERVER}.log"

cd ${JBOSS_HOME}/bin

#################################################### # # We setup defaults for the server to run # Then we look for a properties files for this server # The properties file should override any or all of these defaults ####################################### # bind to a specific IP or default to all ips on this server hostIp="0.0.0.0" jvmDebugPort="8787" jmxRemotePort="1999"

############## # The directory where server setup files will be serverSetupDir="/apps/inet/server/${SERVER}" # Directory where database deployment files will be # This directory is read just like server/inet/deploy is serverDeployDir=${serverSetupDir}/deploy # The properties file for properties above setup="${serverSetupDir}/${SERVER}.properties"

if [[ -f ${setup} ]] then echo "Reading server setup from ${setup}" . ${setup} else echo "No setup file found at ${setup}. Using defaults" fi

# We will get jboss errors if the serverDeployDir does not exsist if [[ ! -d ${serverDeployDir} ]] then echo "WARN: server deploy dir ${serverDeployDir} does not exsist. creating ..." mkdir -p ${serverDeployDir} fi

# Use the maximum available, or set MAX_FD != -1 to use that MAX_FD="maximum"

# # Helper to complain. # warn() { echo "${PROGNAME}: $*" }

# # Helper to puke. # die() { warn $* exit 1 }

# Increase the maximum file descriptors if we can ulimit -n 1024

# Setup the classpath runjar="$JBOSS_HOME/bin/run.jar" if [ ! -f "$runjar" ]; then die "Missing required file: $runjar" fi JBOSS_BOOT_CLASSPATH="$runjar"

# Include the JDK javac compiler for JSP pages. The default is for a Sun JDK # compatible distribution which JAVA_HOME points to if [ "x$JAVAC_JAR" = "x" ]; then JAVAC_JAR="$JAVA_HOME/lib/tools.jar" fi

if [ "x$JBOSS_CLASSPATH" = "x" ]; then JBOSS_CLASSPATH="$JBOSS_BOOT_CLASSPATH:$JAVAC_JAR" else JBOSS_CLASSPATH="$JBOSS_CLASSPATH:$JBOSS_BOOT_CLASSPATH:$JAVAC_JAR" fi

INET_CLASSPATH="/apps/inet/conf/spring" CLASSPATH="$_CLASSPATH:$JBOSS_CLASSPATH"

DEBUG_OPTS="-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=${jvmDebugPort},server=y,suspend=n" JMX_OPTS="-Dcom.sun.management.jmxremote" JMX_OPTS="${JMX_OPTS} -Dcom.sun.management.jmxremote.port=${jmxRemotePort}" JMX_OPTS="${JMX_OPTS} -Dcom.sun.management.jmxremote.authenticate=false" JMX_OPTS="${JMX_OPTS} -Dcom.sun.management.jmxremote.ssl=false"

# don't use JMX or DEBUG on this server #DEBUG_OPTS="" #JMX_OPTS=""

#LOG_OPTS="-Dlog4j.configuration=file:/apps/inet/conf/log4j/log4j.xml" LOG_OPTS="-Dlog4j.debug=true"

# set MaxPermSize to avoid "java.lang.OutOfMemoryError: PermGen" space error # gcInterval time is set to avoid excessive CPU usage for garbage collection # recommendations are between ten minutes (600000) & one hour (3600000) # see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6200091 # JAVA_MEM="-Xms712m -Xmx712m -XX:MaxPermSize=196m -Dsun.rmi.dgc.client.gcInterval=600000 -Dsun.rmi.dgc.server.gcInterval=600000" SERVER_OPTS="-server" JAVA_OPTS="${SERVER_OPTS} ${JAVA_MEM} ${DEBUG_OPTS} ${JMX_OPTS} ${JAVA_OPTS}"

# Setup JBoss sepecific properties JAVA_OPTS="-Dprogram.name=inetDev $JAVA_OPTS"

# Setup the java endorsed dirs JBOSS_ENDORSED_DIRS="$JBOSS_HOME/lib/endorsed"

PTI_ARGS="-Djconfig.filewatcher=false -Dhostname=$HOSTNAME -Dconfig.dir=/apps/inet/conf -Ddata.dir=/data/inet -Dinet.server=${SERVER} -Dlog.dir=/log/ -Dbatchconfig.dir=/apps/inet/conf -Dtest=yes -Dlogfile=${LOGFILE}"

# DIE DIE DIE JBOSS_PID=$(cat $pid) kill $JBOSS_PID 2>/dev/null r=$? if (( $r == 0 )) then /bin/echo -n "shutdown running instance" fi while (( $r == 0 )) do /bin/echo -n "." sleep 3 kill $JBOSS_PID 2>/dev/null r=$? done

echo "rotate server logs" touch ${LOGFILE}1 /bin/mv -f ${LOGFILE}1 ${LOGFILE}2 touch ${LOGFILE}0 /bin/mv -f ${LOGFILE}0 ${LOGFILE}1 touch ${LOGFILE} /bin/mv -f ${LOGFILE} ${LOGFILE}0 touch ${LOGFILE}

/bin/echo

# Display our environment echo "=========================================================================" echo "" echo " JBoss Bootstrap Environment" echo "" echo " SERVER: $SERVER" echo " Host IP: $hostIp" echo " JVM Debug Port: $jvmDebugPort" echo " JMX Remote Port: $jmxRemotePort" echo "" echo " JBOSS_HOME: $JBOSS_HOME" echo "" echo " JAVA: $JAVA" echo "" echo " LOGFILE: $LOGFILE" echo "" echo " JAVA_OPTS: $JAVA_OPTS $LOG_OPTS" echo "" echo " PTI_ARGS: $PTI_ARGS" echo "" echo " CLASSPATH: $CLASSPATH" echo "" echo "=========================================================================" echo ""

# note that "-b0.0.0.0" binds to all ports. # Execute the JVM in the background "$JAVA" $JAVA_OPTS $LOG_OPTS -Djava.endorsed.dirs="$JBOSS_ENDORSED_DIRS" -classpath "$CLASSPATH" ${PTI_ARGS} org.jboss.Main "--host=${hostIp}" "--configuration=${SERVER}" > $LOGFILE 2>&1 & JBOSS_PID=$!

echo $JBOSS_PID > $pid echo "You can follow along at home by running:" echo "tail -f $LOGFILE" #stopJBoss

#!/bin/bash ### ====================================================================== ### ## ## ## JBoss Shutdown Script ## ## ## ### ====================================================================== ###

export JAVA_HOME="/apps/java/default" export JBOSS_HOME="/apps/jboss/default" export PATH=${JAVA_HOME}/bin:${PATH} JAVA=${JAVA_HOME}/bin/java

# make the JBOSS_HOME the real path not a slimebolic link. WD=$(/bin/pwd) cd ${JBOSS_HOME} jb=$(/bin/pwd) export JBOSS_HOME="$jb" cd $WD

CP="${JBOSS_HOME}/bin/shutdown.jar:${JBOSS_HOME}/client/jbossall-client.jar" CLASSPATH="$CP" export CLASSPATH

PROGNAME=`basename $0`

# trick to find which server we are running WD=$(/bin/pwd)

case "${0}" in /*) cmdDir=$(dirname "$0") ;; *) cmdDir=$(dirname "${WD}/$0") ;; esac

cd $cmdDir wrkDir=$(/bin/pwd) SERVER=$(echo $wrkDir sed -e "s^${JBOSS_HOME}/server/^^" sed -e "s^/.*^^")

#################################################### # # We setup defaults for the server to run # Then we look for a properties files for this server # The properties file should override any or all of these defaults ####################################### # bind to a specific IP or default to all ips on this server hostIp=$(/bin/hostname)

############## # The directory where server setup files will be serverSetupDir="/apps/inet/server/${SERVER}" # Directory where database deployment files will be # This directory is read just like server/inet/deploy is serverDeployDir=${serverSetupDir}/deploy # The properties file for properties above setup="${serverSetupDir}/${SERVER}.properties"

if [[ -f ${setup} ]] then echo "Reading server setup from ${setup}" . ${setup} else echo "No setup file found at ${setup}. Using defaults" fi

JBOSS_SERVER=${hostIp}":1099" cd ${JBOSS_HOME}/bin echo "Stopping server: $SERVER on $hostIp" ${JAVA} -classpath $CP org.jboss.Shutdown --server=$JBOSS_SERVER $@

#<instance>.sh

#!/bin/bash # # Control script for starting and stopping inet server on JBoss # # Usage: inet <startstoprestartstatus> # # First task is to determine which server we want to start # Since we can not do this from the arguemenst we assume the # script is located in the bin directory of the server we want to control. #

# # Print a usage message # function usage() { echo "Usage: $0 {startstoprestartstatus}" exit 1 }

# # sets SERVER, SERVERDIR and PROG # This depends on the this script being in the bin directory or the server # function setServer() { PROG=$(/bin/basename $0)

# trick to find which server we are running WD=$(/bin/pwd)

case "${0}" in /*) cmdDir=$(dirname "$0") ;; *) cmdDir=$(dirname "${WD}/$0") ;; esac

SERVERBINDIR=${cmdDir} cd $cmdDir/.. # this should be the server dir SERVERDIR=$(/bin/pwd) SERVER=$(/bin/basename ${SERVERDIR}) cd ${WD} }

# # reverses isUp into a wait for servr to be down function isDown(){

serverHostname=$1 retries=$2 TIMEOUT=10 n=0 while (( $n < $retries )) do sleep $TIMEOUT n=$(( $n + 1 )) $SERVERBINDIR/isUp.sh $serverHostname 0 state=$? if (( $state != 0 )) then return 0 fi done return -1

}

if [[ $# != 1 ]] then usage fi

setServer hn=$(/bin/hostname)

case "$1" in start) echo "$PROG: Starting $SERVER: " $SERVERBINDIR/isUp.sh $hn 0 ret=$? if [[ $ret != 0 ]] then $SERVERBINDIR/startJBoss $SERVERBINDIR/isUp.sh $hn 12 ret=$? exit $ret else echo "$PROG: Server is up. First stop the server" exit -1 fi ;; stop) echo "$PROG: Shutting down $SERVER: " $SERVERBINDIR/isUp.sh $hn 0 ret=$? if [[ $ret = 0 ]] then $SERVERBINDIR/stopJBoss fi isDown $hn 12 ret=$? if [[ $ret = 0 ]] then echo "$PROG: server $SERVER is down" exit 0 else echo "$PROG: server $SERVER is up" exit 1 fi ;; restart) $0 stop $0 start ;; status) $SERVERBINDIR/isUp.sh $hn 0 ret=$? if [[ $ret = 0 ]] then echo "$PROG: server $SERVER is up" exit $ret else echo "$PROG: server $SERVER is down" exit $ret fi ;; *) usage ;; esac

exit 0

#isUp.sh

#!/bin/sh ### ====================================================================== ### ## ## ## JBoss IsUp Script ## ## ## ### ====================================================================== ###

jmxPort="1099"

export JAVA_HOME="/apps/java/default" export PATH=${JAVA_HOME}/bin:${PATH} export JBOSS_HOME="/apps/jboss/default" JAVA="${JAVA_HOME}/bin/java"

DIRNAME=`dirname $0` PROGNAME=`basename $0`

#SERVER=$(/bin/hostname)

SERVER_NAME="$1" RETRIES="$2" TIMEOUT="10"

# # Helper to complain. # die() { echo "${PROGNAME}: $*" exit 1 }

# Setup the classpath # we put a jndi.properties into the same dir as the command and add # DIRNAME to the classpath JBOSS_CLASSPATH="${DIRNAME}:$JBOSS_HOME/bin/twiddle.jar" JBOSS_CLASSPATH="$JBOSS_CLASSPATH" JBOSS_CLASSPATH="$JBOSS_CLASSPATH:$JBOSS_HOME/client/jbossall-client.jar" JBOSS_CLASSPATH="$JBOSS_CLASSPATH:$JBOSS_HOME/client/getopt.jar" JBOSS_CLASSPATH="$JBOSS_CLASSPATH:$JBOSS_HOME/client/log4j.jar" JBOSS_CLASSPATH="$JBOSS_CLASSPATH:$JBOSS_HOME/lib/jboss-jmx.jar"

# Setup the java endorsed dirs JBOSS_ENDORSED_DIRS="$JBOSS_HOME/lib/endorsed"

getState(){ # Execute the JVM response=$($JAVA $JAVA_OPTS -Djava.endorsed.dirs="$JBOSS_ENDORSED_DIRS" -Dprogram.name="$PROGNAME" -classpath $JBOSS_CLASSPATH org.jboss.console.twiddle.Twiddle --server=${SERVER_NAME}:${jmxPort} serverinfo -d 2>/dev/null ) ret=$? if (( $ret == 0 )) then state=1 else state=0 fi }

getState if (( $state > 0 )) then echo "inet server $SERVER_NAME is Up." exit 0 fi

n=0 while (( $n < $RETRIES )) do sleep $TIMEOUT n=$(( $n + 1 )) getState if (( $state > 0 )) then echo "inet server $SERVER_NAME is Up." exit 0 fi done

exit -1