28.4. Kickstart Options

The following options can be placed in a kickstart file. If you prefer to use a graphical interface for creating your kickstart file, use the Kickstart Configurator application. Refer to Chapter 29, Kickstart Configurator for details.
Note

If the option is followed by an equals mark (=), a value must be specified after it. In the example commands, options in brackets ([]) are optional arguments for the command.

autopart (optional)

Automatically create partitions — 1 GB or more root (/) partition, a swap partition, and an appropriate boot partition for the architecture. One or more of the default partition sizes can be redefined with the part directive.
ignoredisk (optional)

Causes the installer to ignore the specified disks. This is useful if you use autopartition and want to be sure that some disks are ignored. For example, without ignoredisk, attempting to deploy on a SAN-cluster the kickstart would fail, as the installer detects passive paths to the SAN that return no partition table.

The ignoredisk option is also useful if you have multiple paths to your disks.

The syntax is:

ignoredisk –drives=drive1,drive2,…

where driveN is one of sda, sdb,…, hda,… etc.
autostep (optional)

Similar to interactive except it goes to the next screen for you. It is used mostly for debugging.

*

–autoscreenshot — Take a screenshot at every step during installation and copy the images over to /root/anaconda-screenshots after installation is complete. This is most useful for documentation.

auth or authconfig (required)

Sets up the authentication options for the system. It is similar to the authconfig command, which can be run after the install. By default, passwords are normally encrypted and are not shadowed.

*

–enablemd5 — Use md5 encryption for user passwords.
*

–enablenis — Turns on NIS support. By default, –enablenis uses whatever domain it finds on the network. A domain should almost always be set by hand with the –nisdomain= option.
*

–nisdomain= — NIS domain name to use for NIS services.
*

–nisserver= — Server to use for NIS services (broadcasts by default).
*

–useshadow or –enableshadow — Use shadow passwords.
*

–enableldap — Turns on LDAP support in /etc/nsswitch.conf, allowing your system to retrieve information about users (UIDs, home directories, shells, etc.) from an LDAP directory. To use this option, you must install the nss_ldap package. You must also specify a server and a base DN (distinguished name) with –ldapserver= and –ldapbasedn=.
*

–enableldapauth — Use LDAP as an authentication method. This enables the pam_ldap module for authentication and changing passwords, using an LDAP directory. To use this option, you must have the nss_ldap package installed. You must also specify a server and a base DN with –ldapserver= and –ldapbasedn=.
*

–ldapserver= — If you specified either –enableldap or –enableldapauth, use this option to specify the name of the LDAP server to use. This option is set in the /etc/ldap.conf file.
*

–ldapbasedn= — If you specified either –enableldap or –enableldapauth, use this option to specify the DN in your LDAP directory tree under which user information is stored. This option is set in the /etc/ldap.conf file.
*

–enableldaptls — Use TLS (Transport Layer Security) lookups. This option allows LDAP to send encrypted usernames and passwords to an LDAP server before authentication.
*

–enablekrb5 — Use Kerberos 5 for authenticating users. Kerberos itself does not know about home directories, UIDs, or shells. If you enable Kerberos, you must make users’ accounts known to this workstation by enabling LDAP, NIS, or Hesiod or by using the /usr/sbin/useradd command. If you use this option, you must have the pam_krb5 package installed.
*

–krb5realm= — The Kerberos 5 realm to which your workstation belongs.
*

–krb5kdc= — The KDC (or KDCs) that serve requests for the realm. If you have multiple KDCs in your realm, separate their names with commas (,).
*

–krb5adminserver= — The KDC in your realm that is also running kadmind. This server handles password changing and other administrative requests. This server must be run on the master KDC if you have more than one KDC.
*

–enablehesiod — Enable Hesiod support for looking up user home directories, UIDs, and shells. More information on setting up and using Hesiod on your network is in /usr/share/doc/glibc-2.x.x/README.hesiod, which is included in the glibc package. Hesiod is an extension of DNS that uses DNS records to store information about users, groups, and various other items.
*

–hesiodlhs — The Hesiod LHS (”left-hand side”) option, set in /etc/hesiod.conf. This option is used by the Hesiod library to determine the name to search DNS for when looking up information, similar to LDAP’s use of a base DN.
*

–hesiodrhs — The Hesiod RHS (”right-hand side”) option, set in /etc/hesiod.conf. This option is used by the Hesiod library to determine the name to search DNS for when looking up information, similar to LDAP’s use of a base DN.
Tip

To look up user information for “jim”, the Hesiod library looks up jim.passwd, which should resolve to a TXT record that looks like what his passwd entry would look like (jim:*:501:501:Jungle Jim:/home/jim:/bin/bash). For groups, the situation is identical, except jim.group would be used.

Looking up users and groups by number is handled by making “501.uid” a CNAME for “jim.passwd”, and “501.gid” a CNAME for “jim.group”. Note that the library does not place a period . in front of the LHS and RHS values when performing a search. Therefore the LHS and RHS values need to have a period placed in front of them in order if they require this.
*

–enablesmbauth — Enables authentication of users against an SMB server (typically a Samba or Windows server). SMB authentication support does not know about home directories, UIDs, or shells. If you enable SMB, you must make users’ accounts known to the workstation by enabling LDAP, NIS, or Hesiod or by using the /usr/sbin/useradd command to make their accounts known to the workstation. To use this option, you must have the pam_smb package installed.
*

–smbservers= — The name of the server(s) to use for SMB authentication. To specify more than one server, separate the names with commas (,).
*

–smbworkgroup= — The name of the workgroup for the SMB servers.
*

–enablecache — Enables the nscd service. The nscd service caches information about users, groups, and various other types of information. Caching is especially helpful if you choose to distribute information about users and groups over your network using NIS, LDAP, or hesiod.

bootloader (required)

Specifies how the boot loader should be installed. This option is required for both installations and upgrades.

*

–append= — Specifies kernel parameters. To specify multiple parameters, separate them with spaces. For example:

bootloader –location=mbr –append=”hdd=ide-scsi ide=nodma”

*

–driveorder — Specify which drive is first in the BIOS boot order. For example:

bootloader –driveorder=sda,hda

*

–location= — Specifies where the boot record is written. Valid values are the following: mbr (the default), partition (installs the boot loader on the first sector of the partition containing the kernel), or none (do not install the boot loader).
*

–password= — If using GRUB, sets the GRUB boot loader password to the one specified with this option. This should be used to restrict access to the GRUB shell, where arbitrary kernel options can be passed.
*

–md5pass= — If using GRUB, similar to –password= except the password should already be encrypted.
*

–upgrade — Upgrade the existing boot loader configuration, preserving the old entries. This option is only available for upgrades.

clearpart (optional)

Removes partitions from the system, prior to creation of new partitions. By default, no partitions are removed.
Note

If the clearpart command is used, then the –onpart command cannot be used on a logical partition.

*

–all — Erases all partitions from the system.
*

–drives= — Specifies which drives to clear partitions from. For example, the following clears all the partitions on the first two drives on the primary IDE controller:

clearpart –drives=hda,hdb –all

*

–initlabel — Initializes the disk label to the default for your architecture (for example msdos for x86 and gpt for Itanium). It is useful so that the installation program does not ask if it should initialize the disk label if installing to a brand new hard drive.
*

–linux — Erases all Linux partitions.
*

–none (default) — Do not remove any partitions.

cmdline (optional)

Perform the installation in a completely non-interactive command line mode. Any prompts for interaction halts the install. This mode is useful on IBM System z systems with the x3270 console.
device (optional)

On most PCI systems, the installation program autoprobes for Ethernet and SCSI cards properly. On older systems and some PCI systems, however, kickstart needs a hint to find the proper devices. The device command, which tells the installation program to install extra modules, is in this format:

device –opts=

*

— Replace with either scsi or eth.
*

— Replace with the name of the kernel module which should be installed.
*

–opts= — Mount options to use for mounting the NFS export. Any options that can be specified in /etc/fstab for an NFS mount are allowed. The options are listed in the nfs(5) man page. Multiple options are separated with a comma.

driverdisk (optional)

Driver diskettes can be used during kickstart installations. You must copy the driver diskettes’s contents to the root directory of a partition on the system’s hard drive. Then you must use the driverdisk command to tell the installation program where to look for the driver disk.

driverdisk [--type=]

Alternatively, a network location can be specified for the driver diskette:

driverdisk –source=ftp://path/to/dd.img
driverdisk –source=http://path/to/dd.img
driverdisk –source=nfs:host:/path/to/img

*

— Partition containing the driver disk.
*

–type= — File system type (for example, vfat or ext2).

firewall (optional)

This option corresponds to the Firewall Configuration screen in the installation program:

firewall –enabled|–disabled [--trust=] [--port=]

*

–enabled or –enable — Reject incoming connections that are not in response to outbound requests, such as DNS replies or DHCP requests. If access to services running on this machine is needed, you can choose to allow specific services through the firewall.
*

–disabled or –disable — Do not configure any iptables rules.
*

–trust= — Listing a device here, such as eth0, allows all traffic coming from that device to go through the firewall. To list more than one device, use –trust eth0 –trust eth1. Do NOT use a comma-separated format such as –trust eth0, eth1.
*

— Replace with one or more of the following to allow the specified services through the firewall.
o

–ssh
o

–telnet
o

–smtp
o

–http
o

–ftp
*

–port= — You can specify that ports be allowed through the firewall using the port:protocol format. For example, to allow IMAP access through your firewall, specify imap:tcp. Numeric ports can also be specified explicitly; for example, to allow UDP packets on port 1234 through, specify 1234:udp. To specify multiple ports, separate them by commas.

firstboot (optional)

Determine whether the Setup Agent starts the first time the system is booted. If enabled, the firstboot package must be installed. If not specified, this option is disabled by default.

*

–enable or –enabled — The Setup Agent is started the first time the system boots.
*

–disable or –disabled — The Setup Agent is not started the first time the system boots.
*

–reconfig — Enable the Setup Agent to start at boot time in reconfiguration mode. This mode enables the language, mouse, keyboard, root password, security level, time zone, and networking configuration options in addition to the default ones.

halt (optional)

Halt the system after the installation has successfully completed. This is similar to a manual installation, where anaconda displays a message and waits for the user to press a key before rebooting. During a kickstart installation, if no completion method is specified, the reboot option is used as default.

The halt option is roughly equivalent to the shutdown -h command.

For other completion methods, refer to the poweroff, reboot, and shutdown kickstart options.
graphical (optional)

Perform the kickstart installation in graphical mode. This is the default.
install (optional)

Tells the system to install a fresh system rather than upgrade an existing system. This is the default mode. For installation, you must specify the type of installation from cdrom, harddrive, nfs, or url (for FTP or HTTP installations). The install command and the installation method command must be on separate lines.

*

cdrom — Install from the first CD-ROM drive on the system.
*

harddrive — Install from a Red Hat installation tree on a local drive, which must be either vfat or ext2.
o

–biospart=

BIOS partition to install from (such as 82).
o

–partition=

Partition to install from (such as sdb2).
o

–dir=

Directory containing the variant directory of the installation tree.

For example:

harddrive –partition=hdb2 –dir=/tmp/install-tree

*

nfs — Install from the NFS server specified.
o

–server=

Server from which to install (hostname or IP).
o

–dir=

Directory containing the variant directory of the installation tree.
o

–opts=

Mount options to use for mounting the NFS export. (optional)

For example:

nfs –server=nfsserver.example.com –dir=/tmp/install-tree

*

url — Install from an installation tree on a remote server via FTP or HTTP.

For example:

url –url http:///

or:

url –url ftp://:@/

interactive (optional)

Uses the information provided in the kickstart file during the installation, but allow for inspection and modification of the values given. You are presented with each screen of the installation program with the values from the kickstart file. Either accept the values by clicking Next or change the values and click Next to continue. Refer to the autostep command.
iscsi (optional)

issci –ipaddr= [options].

*

–target —
*

–port= —
*

–user= —
*

–password= —

key (optional)

Specify an installation key, which is needed to aid in package selection and identify your system for support purposes. This command is Red Hat Enterprise Linux-specific; it has no meaning for Fedora and will be ignored.

*

–skip — Skip entering a key. Usually if the key command is not given, anaconda will pause at this step to prompt for a key. This option allows automated installation to continue if you do not have a key or do not want to provide one.

keyboard (required)

Sets system keyboard type. Here is the list of available keyboards on i386, Itanium, and Alpha machines:

be-latin1, bg, br-abnt2, cf, cz-lat2, cz-us-qwertz, de, de-latin1,
de-latin1-nodeadkeys, dk, dk-latin1, dvorak, es, et, fi, fi-latin1,
fr, fr-latin0, fr-latin1, fr-pc, fr_CH, fr_CH-latin1, gr, hu, hu101,
is-latin1, it, it-ibm, it2, jp106, la-latin1, mk-utf, no, no-latin1,
pl, pt-latin1, ro_win, ru, ru-cp1251, ru-ms, ru1, ru2, ru_win,
se-latin1, sg, sg-latin1, sk-qwerty, slovene, speakup, speakup-lt,
sv-latin1, sg, sg-latin1, sk-querty, slovene, trq, ua, uk, us, us-acentos

The file /usr/lib/python2.2/site-packages/rhpl/keyboard_models.py also contains this list and is part of the rhpl package.
lang (required)

Sets the language to use during installation and the default language to use on the installed system. For example, to set the language to English, the kickstart file should contain the following line:

lang en_US

The file /usr/share/system-config-language/locale-list provides a list of the valid language codes in the first column of each line and is part of the system-config-language package.

Certain languages (mainly Chinese, Japanese, Korean, and Indic languages) are not supported during text mode installation. If one of these languages is specified using the lang command, installation will continue in English though the running system will have the specified langauge by default.
langsupport (deprecated)

The langsupport keyword is deprecated and its use will cause an error message to be printed to the screen and installation to halt. Instead of using the langsupport keyword, you should now list the support package groups for all languages you want supported in the %packages section of your kickstart file. For instance, adding support for French means you should add the following to %packages:

@french-support

logvol (optional)

Create a logical volume for Logical Volume Management (LVM) with the syntax:

logvol –vgname= –size= –name=

The options are as follows:

*

–noformat — Use an existing logical volume and do not format it.
*

–useexisting — Use an existing logical volume and reformat it.
*

–fstype= — Sets the file system type for the logical volume. Valid values are ext2, ext3, swap, and vfat.
*

–fsoptions= — Specifies a free form string of options to be used when mounting the filesystem. This string will be copied into the /etc/fstab file of the installed system and should be enclosed in quotes.
*

–bytes-per-inode= — Specifies the size of inodes on the filesystem to be made on the logical volume. Not all filesystems support this option, so it is silently ignored for those cases.
*

–grow= — Tells the logical volume to grow to fill available space (if any), or up to the maximum size setting.
*

–maxsize= — The maximum size in megabytes when the logical volume is set to grow. Specify an integer value here, and do not append the number with MB.
*

–recommended= — Determine the size of the logical volume automatically.
*

–percent= — Specify the size of the logical volume as a percentage of available space in the volume group.

Create the partition first, create the logical volume group, and then create the logical volume. For example:

part pv.01 –size 3000
volgroup myvg pv.01
logvol / –vgname=myvg –size=2000 –name=rootvol

logging (optional)

This command controls the error logging of anaconda during installation. It has no effect on the installed system.

*

–host= — Send logging information to the given remote host, which must be running a syslogd process configured to accept remote logging.
*

–port= — If the remote syslogd process uses a port other than the default, it may be specified with this option.
*

–level= — One of debug, info, warning, error, or critical.

Specify the minimum level of messages that appear on tty3. All messages will still be sent to the log file regardless of this level, however.

mediacheck (optional)

If given, this will force anaconda to run mediacheck on the installation media. This command requires that installs be attended, so it is disabled by default.
monitor (optional)

If the monitor command is not given, anaconda will use X to automatically detect your monitor settings. Please try this before manually configuring your monitor.

*

–hsync= — Specifies the horizontal sync frequency of the monitor.
*

–monitor= — Use specified monitor; monitor name should be from the list of monitors in /usr/share/hwdata/MonitorsDB from the hwdata package. The list of monitors can also be found on the X Configuration screen of the Kickstart Configurator. This is ignored if –hsync or –vsync is provided. If no monitor information is provided, the installation program tries to probe for it automatically.
*

–noprobe= — Do not try to probe the monitor.
*

–vsync= — Specifies the vertical sync frequency of the monitor.

mouse (deprecated)

The mouse keyword is deprecated.
network (optional)

Configures network information for the system. If the kickstart installation does not require networking (in other words, it is not installed over NFS, HTTP, or FTP), networking is not configured for the system. If the installation does require networking and network information is not provided in the kickstart file, the installation program assumes that the installation should be done over eth0 via a dynamic IP address (BOOTP/DHCP), and configures the final, installed system to determine its IP address dynamically. The network option configures networking information for kickstart installations via a network as well as for the installed system.

*

–bootproto= — One of dhcp, bootp, or static.

It defaults to dhcp. bootp and dhcp are treated the same.

The DHCP method uses a DHCP server system to obtain its networking configuration. As you might guess, the BOOTP method is similar, requiring a BOOTP server to supply the networking configuration. To direct a system to use DHCP:

network –bootproto=dhcp

To direct a machine to use BOOTP to obtain its networking configuration, use the following line in the kickstart file:

network –bootproto=bootp

The static method requires that you enter all the required networking information in the kickstart file. As the name implies, this information is static and are used during and after the installation. The line for static networking is more complex, as you must include all network configuration information on one line. You must specify the IP address, netmask, gateway, and nameserver. For example: (the “\” indicates that this should be read as one continuous line):

network –bootproto=static –ip=10.0.2.15 –netmask=255.255.255.0 \
–gateway=10.0.2.254 –nameserver=10.0.2.1

If you use the static method, be aware of the following two restrictions:
o

All static networking configuration information must be specified on one line; you cannot wrap lines using a backslash, for example.
o

You can also configure multiple nameservers here. To do so, specify them as a comma-delimited list in the command line. For example:

network –bootproto=static –ip=10.0.2.15 –netmask=255.255.255.0 \
–gateway=10.0.2.254 –nameserver 192.168.2.1,192.168.3.1

*

–device= — Used to select a specific Ethernet device for installation. Note that using –device= is not effective unless the kickstart file is a local file (such as ks=floppy), since the installation program configures the network to find the kickstart file. For example:

network –bootproto=dhcp –device=eth0

*

–ip= — IP address for the machine to be installed.
*

–gateway= — Default gateway as an IP address.
*

–nameserver= — Primary nameserver, as an IP address.
*

–nodns — Do not configure any DNS server.
*

–netmask= — Netmask for the installed system.
*

–hostname= — Hostname for the installed system.
*

–ethtool= — Specifies additional low-level settings for the network device which will be passed to the ethtool program.
*

–essid= — The network ID for wireless networks.
*

–wepkey= — The encryption key for wireless networks.
*

–onboot= — Whether or not to enable the device at boot time.
*

–class= — The DHCP class.
*

–mtu= — The MTU of the device.
*

–noipv4 — Disable IPv4 on this device.
*

–noipv6 — Disable IPv6 on this device.

multipath (optional)

multipath –name= –device= –rule=
part or partition (required for installs, ignored for upgrades)

Creates a partition on the system.

If more than one Red Hat Enterprise Linux installation exists on the system on different partitions, the installation program prompts the user and asks which installation to upgrade.
Warning

All partitions created are formatted as part of the installation process unless –noformat and –onpart are used.

For a detailed example of part in action, refer to Section 28.4.1, “Advanced Partitioning Example”.

*

— The is where the partition is mounted and must be of one of the following forms:
o

/

For example, /, /usr, /home
o

swap

The partition is used as swap space.

To determine the size of the swap partition automatically, use the –recommended option:

swap –recommended

The minimum size of the automatically-generated swap partition is no smaller than the amount of RAM in the system and no larger than twice the amount of RAM in the system.
o

raid.

The partition is used for software RAID (refer to raid).
o

pv.

The partition is used for LVM (refer to logvol).
*

–size= — The minimum partition size in megabytes. Specify an integer value here such as 500. Do not append the number with MB.
*

–grow — Tells the partition to grow to fill available space (if any), or up to the maximum size setting.
*

–maxsize= — The maximum partition size in megabytes when the partition is set to grow. Specify an integer value here, and do not append the number with MB.
*

–noformat — Tells the installation program not to format the partition, for use with the –onpart command.
*

–onpart= or –usepart= — Put the partition on the already existing device. For example:

partition /home –onpart=hda1

puts /home on /dev/hda1, which must already exist.
*

–ondisk= or –ondrive= — Forces the partition to be created on a particular disk. For example, –ondisk=sdb puts the partition on the second SCSI disk on the system.
*

–asprimary — Forces automatic allocation of the partition as a primary partition, or the partitioning fails.
*

–type= (replaced by fstype) — This option is no longer available. Use fstype.
*

–fstype= — Sets the file system type for the partition. Valid values are ext2, ext3, swap, and vfat.
*

–start= — Specifies the starting cylinder for the partition. It requires that a drive be specified with –ondisk= or ondrive=. It also requires that the ending cylinder be specified with –end= or the partition size be specified with –size=.
*

–end= — Specifies the ending cylinder for the partition. It requires that the starting cylinder be specified with –start=.
*

–bytes-per-inode= — Specifies the size of inodes on the filesystem to be made on the partition. Not all filesystems support this option, so it is silently ignored for those cases.
*

–recommended — Determine the size of the partition automatically.
*

–onbiosdisk — Forces the partition to be created on a particular disk as discovered by the BIOS.

Note

If partitioning fails for any reason, diagnostic messages appear on virtual console 3.
poweroff (optional)

Shut down and power off the system after the installation has successfully completed. Normally during a manual installation, anaconda displays a message and waits for the user to press a key before rebooting. During a kickstart installation, if no completion method is specified, the reboot option is used as default.

The poweroff option is roughly equivalent to the shutdown -p command.
Note

The poweroff option is highly dependent on the system hardware in use. Specifically, certain hardware components such as the BIOS, APM (advanced power management), and ACPI (advanced configuration and power interface) must be able to interact with the system kernel. Contact your manufacturer for more information on you system’s APM/ACPI abilities.

For other completion methods, refer to the halt, reboot, and shutdown kickstart options.
raid (optional)

Assembles a software RAID device. This command is of the form:

raid –level= –device=

*

— Location where the RAID file system is mounted. If it is /, the RAID level must be 1 unless a boot partition (/boot) is present. If a boot partition is present, the /boot partition must be level 1 and the root (/) partition can be any of the available types. The (which denotes that multiple partitions can be listed) lists the RAID identifiers to add to the RAID array.
*

–level= — RAID level to use (0, 1, or 5).
*

–device= — Name of the RAID device to use (such as md0 or md1). RAID devices range from md0 to md15, and each may only be used once.
*

–bytes-per-inode= — Specifies the size of inodes on the filesystem to be made on the RAID device. Not all filesystems support this option, so it is silently ignored for those cases.
*

–spares= — Specifies the number of spare drives allocated for the RAID array. Spare drives are used to rebuild the array in case of drive failure.
*

–fstype= — Sets the file system type for the RAID array. Valid values are ext2, ext3, swap, and vfat.
*

–fsoptions= — Specifies a free form string of options to be used when mounting the filesystem. This string will be copied into the /etc/fstab file of the installed system and should be enclosed in quotes.
*

–noformat — Use an existing RAID device and do not format the RAID array.
*

–useexisting — Use an existing RAID device and reformat it.

The following example shows how to create a RAID level 1 partition for /, and a RAID level 5 for /usr, assuming there are three SCSI disks on the system. It also creates three swap partitions, one on each drive.

part raid.01 –size=60 –ondisk=sda
part raid.02 –size=60 –ondisk=sdb
part raid.03 –size=60 –ondisk=sdc

part swap –size=128 –ondisk=sda
part swap –size=128 –ondisk=sdb
part swap –size=128 –ondisk=sdc

part raid.11 –size=1 –grow –ondisk=sda
part raid.12 –size=1 –grow –ondisk=sdb
part raid.13 –size=1 –grow –ondisk=sdc

raid / –level=1 –device=md0 raid.01 raid.02 raid.03
raid /usr –level=5 –device=md1 raid.11 raid.12 raid.13

For a detailed example of raid in action, refer to Section 28.4.1, “Advanced Partitioning Example”.
reboot (optional)

Reboot after the installation is successfully completed (no arguments). Normally, kickstart displays a message and waits for the user to press a key before rebooting.

The reboot option is roughly equivalent to the shutdown -r command.
Note

Use of the reboot option may result in an endless installation loop, depending on the installation media and method.

The reboot option is the default completion method if no other methods are explicitly specified in the kickstart file.

For other completion methods, refer to the halt, poweroff, and shutdown kickstart options.
repo (optional)

Configures additional yum repositories that may be used as sources for package installation. Multiple repo lines may be specified.

repo –name= [--baseurl=| --mirrorlist=]

*

–name= — The repo id. This option is required.
*

–baseurl= — The URL for the repository. The variables that may be used in yum repo config files are not supported here. You may use one of either this option or –mirrorlist, not both.
*

–mirrorlist= — The URL pointing at a list of mirrors for the repository. The variables that may be used in yum repo config files are not supported here. You may use one of either this option or –baseurl, not both.

rootpw (required)

Sets the system’s root password to the argument.

rootpw [--iscrypted]

*

–iscrypted — If this is present, the password argument is assumed to already be encrypted.

selinux (optional)

Sets the state of SELinux on the installed system. SELinux defaults to enforcing in anaconda.

selinux [--disabled|--enforcing|--permissive]

*

–enforcing — Enables SELinux with the default targeted policy being enforced.
Note

If the selinux option is not present in the kickstart file, SELinux is enabled and set to –enforcing by default.
*

–permissive — Outputs warnings based on the SELinux policy, but does not actually enforce the policy.
*

–disabled — Disables SELinux completely on the system.

For complete information regarding SELinux for Red Hat Enterprise Linux, refer to the Red Hat Enterprise Linux Deployment Guide.
services (optional)

Modifies the default set of services that will run under the default runlevel. The services listed in the disabled list will be disabled before the services listed in the enabled list are enabled.

*

–disabled — Disable the services given in the comma separated list.
*

–enabled — Enable the services given in the comma separated list.

shutdown (optional)

Shut down the system after the installation has successfully completed. During a kickstart installation, if no completion method is specified, the reboot option is used as default.

The shutdown option is roughly equivalent to the shutdown command.

For other completion methods, refer to the halt, poweroff, and reboot kickstart options.
skipx (optional)

If present, X is not configured on the installed system.
text (optional)

Perform the kickstart installation in text mode. Kickstart installations are performed in graphical mode by default.
timezone (required)

Sets the system time zone to which may be any of the time zones listed by timeconfig.

timezone [--utc]

*

–utc — If present, the system assumes the hardware clock is set to UTC (Greenwich Mean) time.

upgrade (optional)

Tells the system to upgrade an existing system rather than install a fresh system. You must specify one of cdrom, harddrive, nfs, or url (for FTP and HTTP) as the location of the installation tree. Refer to install for details.
user (optional)

Creates a new user on the system.

user –name= [--groups=] [--homedir=] [--password=] [--iscrypted] [--shell=] [--uid=]

*

–name= — Provides the name of the user. This option is required.
*

–groups= — In addition to the default group, a comma separated list of group names the user should belong to.
*

–homedir= — The home directory for the user. If not provided, this defaults to /home/.
*

–password= — The new user’s password. If not provided, the account will be locked by default.
*

–iscrypted= — Is the password provided by –password already encrypted or not?
*

–shell= — The user’s login shell. If not provided, this defaults to the system default.
*

–uid= — The user’s UID. If not provided, this defaults to the next available non-system UID.

vnc (optional)

Allows the graphical installation to be viewed remotely via VNC. This method is usually preferred over text mode, as there are some size and language limitations in text installs. With no options, this command will start a VNC server on the machine with no password and will print out the command that needs to be run to connect a remote machine.

vnc [--host=] [--port=] [--password=]

*

–host= — Instead of starting a VNC server on the install machine, connect to the VNC viewer process listening on the given hostname.
*

–port= — Provide a port that the remote VNC viewer process is listening on. If not provided, anaconda will use the VNC default.
*

–password= — Set a password which must be provided to connect to the VNC session. This is optional, but recommended.

volgroup (optional)

Use to create a Logical Volume Management (LVM) group with the syntax:

volgroup

The options are as follows:

*

–noformat — Use an existing volume group and do not format it.
*

–useexisting — Use an existing volume group and reformat it.
*

–pesize= — Set the size of the physical extents.

Create the partition first, create the logical volume group, and then create the logical volume. For example:

part pv.01 –size 3000
volgroup myvg pv.01
logvol / –vgname=myvg –size=2000 –name=rootvol

For a detailed example of volgroup in action, refer to Section 28.4.1, “Advanced Partitioning Example”.
xconfig (optional)

Configures the X Window System. If this option is not given, the user must configure X manually during the installation, if X was installed; this option should not be used if X is not installed on the final system.

*

–driver — Specify the X driver to use for the video hardware.
*

–videoram= — Specifies the amount of video RAM the video card has.
*

–defaultdesktop= — Specify either GNOME or KDE to set the default desktop (assumes that GNOME Desktop Environment and/or KDE Desktop Environment has been installed through %packages).
*

–startxonboot — Use a graphical login on the installed system.
*

–resolution= — Specify the default resolution for the X Window System on the installed system. Valid values are 640×480, 800×600, 1024×768, 1152×864, 1280×1024, 1400×1050, 1600×1200. Be sure to specify a resolution that is compatible with the video card and monitor.
*

–depth= — Specify the default color depth for the X Window System on the installed system. Valid values are 8, 16, 24, and 32. Be sure to specify a color depth that is compatible with the video card and monitor.

zerombr (optional)

If zerombr is specified any invalid partition tables found on disks are initialized. This destroys all of the contents of disks with invalid partition tables.
zfcp (optional)

Define a Fiber channel device (IBM System z).

zfcp [--devnum=] [--fcplun=] [--scsiid=] [--scsilun=] [--wwpn=]
%include (optional)

Use the %include /path/to/file command to include the contents of another file in the kickstart file as though the contents were at the location of the %include command in the kickstart file.

Gridshore » Using maven to create an osgi bundle (osgi felix sample step 2)

This is the second step in a series of items about exploring the felix osgi container and some sidesteps to make life easier while developing osgi bundles. You can find the first step here: http://www.gridshore.nl/2008/02/10/starting-with-osgi-using-apache-felix-step-1/

This is so easy, I do not want to spend to much time here. There is a special maven 2 plugin to create a “bundle”, check out the following page that describes the plugin : maven-bundle-plugin.

Create a new maven project using the most basic archetype.

mvn archetype:create -DgroupId= -DartifactId=

Change the packaging of the pom to be “bundle”. Add a dependency to the core and configure the plug in. The possible parameters are described extensively at the mentioned web page. I’ll explain the what and why of the code below, not the theory. The following pom file is the pom of the project example-client in the FelixTryout project on my google code page. As you can see there is a dependency on the training-service and on jetty. i am not going to talk about jetty here. More on that in one of the next steps.

xsi:schemaLocation=”http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd”>
4.0.0
nl.gridshore.samples.bundles
example-client
bundle
1.0-SNAPSHOT
example-client
http://maven.apache.org

${pom.groupId}
training-service
1.0-SNAPSHOT

org.apache.felix
org.osgi.core
1.0.0

org.mortbay.jetty
jetty
6.1.7

org.apache.maven.plugins
maven-compiler-plugin

1.5
1.5

org.apache.felix
maven-bundle-plugin
1.2.0
true

nl.gridshore.samples.bundles.exampleclient.api

nl.gridshore.samples.bundles.exampleclient.impl

${pom.artifactId}

nl.gridshore.samples.bundles.exampleclient.impl.Activator

Gridshore » Starting with OSGi using apache felix (step 1)

I think it was somewhere September 2006 when I first read about OSGi. Immediately I saw opportunities to finally come to my long envisioned Service Component Architecture. On top of that I could fix all these classloader issues as well. So good news. Together with Allard we started evaluating the possibilities of OSGi. We tried starting with spring osgi (I know the name has changed, but this is easier), but we were missing some basic knowledge. So back to the roots, use pure OSGi. Because we were using eclipse for a long time, we started using equinox. We even have given a presentation about OSGi in combination with webservice versioning at a dutch java user conference. Because I wanted to use maven and since I am programming with IntelliJ nowadays I was looking for other options. That is when I got back to felix, which has become a very interesting project. After this long introduction it is time to start explaining what this post is all about. With this post I want to share my first steps with apache felix. Watch out for all other posts about the OSGi felix exploration.

First a general idea about the thing we are going to create and the steps to take.

1. Start a felix instance using java code and interact with the OSGi context from outside
2. Create bundles using maven 2
3. Create a service that is exposed as a bundle
4. Create a simple client

In other posts I want to look at more enterprise possibilities, like exposing using the web, etc. Most of the knowledge I gained for this article I took from the felix website. There are some nice pages about creating bundles, using services, registering listeners. Check their OSGi pages.

grizzly: Grizzly Project Home Page

Writing scalable server applications in the Java™ programming language has always been difficult. Before the advent of the Java New I/O API (NIO), thread management issues made it impossible for a server to scale to thousands of users. The Grizzly framework has been designed to help developers to take advantage of the Java™ NIO API. Grizzly goals is to help developers to build scalable and robust servers using NIO and we are also offering embeddable components supporting HTTP, Bayeux Protocol, Servlet (Partially) and Comet

Grizzlies developers are Jeanfrancois Alexey John Sebastien Hubert Shing Wai Charlie Ken

SQL*Plus Instant Client

Connecting to a Database with SQL*Plus Instant Client

SQL*Plus Instant Client is always ‘remote’ from any database server. To connect to a database you must specify the database using an Oracle Net connection identifier.

An example using an Easy Connection identifier to connect to the HR schema in the MYDB database running on mymachine is:

sqlplus hr/your_password@//mymachine.mydomain:port/MYDB

Alternatively you can use a Net Service Name:

sqlplus hr/your_password@MYDB

Net Service Names can be stored in a number of places, including LDAP. The use of LDAP is recommended to take advantage of the new features of Oracle Database 10g. See the Oracle Database Net Services Reference for more information.

If you want to use Net Service Names configured in a local Oracle Net tnsnames.ora file, then set the environment variable TNS_ADMIN to the directory containing the tnsnames.ora file. For example, on UNIX, if your tnsnames.ora file is in /home/user1 and it defines the Net Service Name MYDB2:

TNS_ADMIN=/home/user1
export TNS_ADMIN
sqlplus hr@MYDB2

If TNS_ADMIN is not set, then an operating system dependent set of directories is examined to find tnsnames.ora. This search path includes looking in the directory specified by the ORACLE_HOME environment variable for network/admin/tnsnames.ora. This is the only reason to set the ORACLE_HOME environment variable for SQL*Plus Instant Client. If ORACLE_HOME is set when running Instant Client applications, it must be set to a directory that exists.

This example assumes the ORACLE_HOME environment variable is set, and the $ORACLE_HOME/network/admin/tnsnames.ora or %ORACLE_HOME%\network\admin\tnsnames.ora file defines the Net Service Name MYDB3:

sqlplus hr@MYDB3

The TWO_TASK (on UNIX) or LOCAL (on Windows) environment variable can be set to a connection identifier. This removes the need to explicitly enter the connection identifier whenever a connection is made in SQL*Plus or SQL*Plus Instant Client. This UNIX example connects to the database known as MYDB4:

TNS_ADMIN=/home/user1
export TNS_ADMIN
TWO_TASK=MYDB4
export TWO_TASK
sqlplus hr

On Windows, TNS_ADMIN and LOCAL may be set in the System Properties. See Configuring SQL*Plus Instant Client on Windows.

SQL*Plus Instant Client

Configuring SQL*Plus Instant Client on Linux (from RPMs)

The RPMs downloaded from OTN install into Oracle specific sub-directories in the /usr file system. The sub-directory structure enables multiple versions of Instant Client to be available.

1.

Add the name of the directory containing the Instant Client libraries to LD_LIBRARY_PATH. Remove any other Oracle directories.

For example, to set LD_LIBRARY_PATH on Solaris in the Bourne or Korn shells:

LD_LIBRARY_PATH=/usr/lib/oracle/10.2.0.1/client/lib:${LD_LIBRARY_PATH}
export LD_LIBRARY_PATH

2.

Make sure the sqlplus executable installed from the RPM is the first found in your PATH. To test, enter which sqlplus which should return /usr/bin/sqlplus. If not, remove any other Oracle directories from PATH, or put /usr/bin before other SQL*Plus executables in PATH, or use an absolute or relative path to start SQL*Plus.

For example, to set PATH in the bash shell:

PATH=/usr/bin:${PATH}
export PATH

If you install multiple versions of SQL*Plus, you may need to change the symbolic link /usr/bin/sqlplus to the version of SQL*Plus matching the libraries in LD_LIBRARY_PATH. For 10.2.0.1, /usr/bin/sqlplus is a symbolic link to the SQL*Plus binary at /usr/lib/oracle/10.2.0.1/client/bin/sqlplus.
3.

Set SQLPATH to the directory containing glogin.sql. For example:

SQLPATH=/usr/lib/oracle/10.2.0.1/client/lib:${SQLPATH}
export SQLPATH

4.

Set Oracle globalization variables required for your locale. A default locale will be assumed if no variables are set. See the Oracle Database Globalization Support Guide for more information.

For example:

NLS_LANG=AMERICAN_AMERICA.UTF8
export NLS_LANG

Oracle Instant Client

Oracle Database Instant Client

Instant Client allows you to run your applications without installing the standard Oracle client or having an ORACLE_HOME. OCI, OCCI, Pro*C, ODBC, and JDBC applications work without modification, while using significantly less disk space than before. Even SQL*Plus can be used with Instant Client. No recompile, no hassle.

ISVs and Partners benefit greatly from packaging Instant Client along with their applications, saving customers the extra step of installing and configuring an Oracle client. Free. The same fully-featured, high-performance applications that Oracle ISVs and partners have always delivered will continue to work, untouched.

Customers can try new packaged applications and Oracle client features quickly without worrying about other installations. Larger enterprises can automate setup and configuration of Instant Client by using installation scripts accessing a central IT repository. Finally, everyone can benefit from the smaller footprint.

Especially for production use. Especially for free.

Weerasak.com

A pretty cool new way of using Distributed OSGi services is from a non-OSGi environment. In the previous post I used an OSGi AuctionService from an OSGi AuctionConsumer in a different VM.
This posting is about using that OSGi service from a non-OSGi consumer. From an AJAX-powered web application that’s running in the browser!

Modules that might be useful for newspapers | groups.drupal.org

This wiki page lists a number of modules useful for newspaper sites. Please add any module you think is missing! A discussion is found at the bottom of the page.
All modules work with Drupal 5 if nothing else is stated. Most descriptions come from the readme or info files (but please add your own comment if it would describe the module better from a newspaper perspective).
Latest addition: Data acquisition section added. “Node grouping” renamed to “Content organization and presentation.” Minor edits.

A few tips on choosing modules

* Make sure that the module fits the Drupal version you’re using.
* Read the readme, to make sure that the module does what you want it to do. Some modules have quite misleading names.
* Check the feature-request list and bug report list for the module. If they are close to empty, it means that the module is barely used, and probably won’t continue to be developed (unless you do it yourself). If the bug list contains serious bugs that haven’t been fixed for some time, it means that maintainance of the module is poor.
* Always try the module on a test site for a while before installing it on your live site.

Must-haves

* CCK, Content Construction Kit, is used to customize node types. Use with sub modules to create data fields with dates, links, buttons, etc. With CCK, you can create a article node type containing fields for section, lead image, editor, publish end-date, location, et cetera. Also, check out the Contemplate module for extended node template customization. There are a number of sub modules.
* The Action module allows you to configure actions for use by other Drupal modules. For example, you can create an action that sends an email message to someone. Another Drupal module may then execute that action.
* Views module allows creation of lists of nodes based on flexible criteria, for example last commented articles, most popular articles, sports articles tagged as top stories. You can choose which fields to display in the lists, and the lists may be themed individually. Also, the lists may be displayed as blocks or pages, and lists can be exported as documents or CSV tables, and may also be broadcasted as RSS feeds. There are a number of sub modules for Views, such as Insert view, which makes it easier to display lists in nodes (for example for read-more links). Other useful extension modules include Views actions links, Views scheduler and Views bonus pack.
* Panels module will help you complex, multicolumn page layouts that can be managed by editors. With Panels, it’s possible to change the layout of the homepage or section pages based on the needs of news content. Panels allows node, view, block or custom content to be assigned arbitrarily to zones in custom layouts, freeing you from the ordinary limitations of the 1:1 relationship between blocks and regions.
* The Pathauto module provides support functions for other modules to automatically generate aliases based on appropriate criteria, for example yoursite.com/year/issue/title-of-article. This is a huge boost when it comes to search engine optimization.
* XML Sitemap to submit and control XML sitemaps, which makes the (right parts of the) site more popular among search engines. If you use XML sitemap and Pathauto, you should increase the weight of XML sitemap to make the paths be written after the aliases have been created. This can be done by editing in the system mySQL table, or through the Module Weight module.

Administration

Customizing user access

* Premium module restricts access to premium content by role. Useful on a news or magazine site where teasers are available to the general public but the full body is only available to privileged users. Premium nodes appear in listings with full title and teaser available to anyone. If a user does not have adequate privileges, the body is replaced with an administrator-defined message (for example, an invitation to join the site). Only dev version available for Drupal 5.
* Content access module allows you to manage permissions for content types by role and author. It allows you to specifiy custom view, edit and delete permissions for each content type. Optionally you can also enable per node access settings, so you can customize the access for each node. This module appears to be more maintained than Node Access, and also to better support multiple access managing modules.
* Node Access module allows you to manage permissions for nodes by role and user. In other words, it implements per node access control for users and groups. With this module, you can restrict access to any individual node without having to use taxonomy. You can assign permission to view, edit or delete each individual node by user or role.
* Menu per role module allows you to restrict access of menu items per roles. Useful if you want blocks or menu items to show only to selected user groups (be it editors, repoters or priviliged users).
* CCK Field Permissions module allows admins to restrict access to specific CCK node type fields to by user roles. This is useful if you, for example, want full-versions of articles available to premium-users only, but still want all users to see parts of the article.
* Registration code module allows administrators to set a registration code or codes that new users must enter before they can complete the registration process. Useful for example if you have a printed password in your magazine to allow readers to access content online.
* Path access provides the means to restrict pages based on their path alias - meaning you can lock out certain user role groups from whole sections of a site using wildcards. Useful mainly to increase security on your site.

Member administration and recruiting

* Logintoboggan module provides a number of neat functions for logging in and registrating, such as re-typing e-mail for verification.
* Members module provides an alternate listing style to Profile module, with a focus on tabular display and an emphasis on roles (including listing by role).
* Account reminder will resend the welcome email to those users who have registered but who have not yet validated their email addresses.
* Inactive user provides automatic handling of inactive users.
* nf registration module adds the ability to have several different membership types, each collecting different data from the user for registration by using custom content types and the combination of nodeprofile and pageroute modules.
* Tellafriend module creates a “tell-a-friend” page to direct traffic towards your site. The Postcard module does a similar job by allowing users to create e-postcards and send a link to their friends.
* Ecommerce module has some functions concerning payment for registration.

News letters

* Simplenews sends html or plain text newsletters to the subscription list. It may be extended with the Simplenews template module.
* The Views Mail module provides a flexible method for sending messages to list of users created by the Views module.

Statistics

* Download count increments a download counter and logs a descriptive message each time an attached file is downloaded.
* Google Analytics module adds Google Analytics javascript tracking code to all your site’s pages. This could be the best choice for sites where non-tech people would like to see statistics.
* Quickstats module is a simple and efficient (from a database point of view) way to count pageviews of nodes. It is intended for heavy traffic sites where performance is key.

Content
Data acquisition

* FeedAPI can create full nodes from Atom and RSS feeds, and can be extended to
accommodate other formats. There is not (yet) a publicly available NITF or NewsML parser, and given the general poor technical quality of feeds generated by most legacy newsroom content management systems, you may be better off creating your own that is tuned to the oddities of your feed.
* Feed Element Mapper is an add-on module for FeedAPI that maps elements on a feed item to CCK fields or taxonomy terms.

Content organization and presentation

* Node Queue module allows site managers to arbitrarily designate nodes as belonging to a group for some purpose. A typical use case would be to create lists of featured items for the front page or a section highlights page. Node queues are available to Views.
* Calais integrates the ThompsonReuters OpenCalais content-analysis service. Node content is submitted automatically for analysis and term extraction through a Web services interface. Extracted terms are inserted into a set of specific vocabularies. This can be used for automatic generation of related-item links, etc.
* Front Page module provides some tools for customizing front page settings, for example to show different front pages for different user roles.
* Sidecontent module allows content to be added (easily) to a side bar block to a node (and only that node).
* Node family module allows you to define relations between content types (such as parent articles and child info-boxes).
* Relativity allows parent-child relationships between nodes to be established, managed and searched. Also a related navigation block.
* Relatedcontent allows privileged users to assemble teasers at the end of a node.
* Cre, content recommendation engine, recommends nodes that have recieved high user ratings. (For example by Fivestar, a simple five-star voting widget for nodes. There are more voting modules available. Most of them use the Votingapi module.)

Customizing node display

* Tweakbox allows you to apply new teaser settings on all or selected nodes, define teaser length per content type, and also to create tables of content based on heading tags.
* Nodeteaser module provides a separate teaser field.
* Paging module allows users to use a tag to break a node up, for specified content types, into multiple pages.
* Print Friendly Pages module allows you to generate printer friendly versions of any node by navigating to www.example.com/node/nid/print, where nid is the node id of content to render.
* Printable module provides a printable page link for all pages on a Drupal site. The pritable version can be themed through theme_printable_page().
* Pdfview is a module to generate pdf files from nodes.

Content handling

* Scheduler module allows nodes to be published and unpublished on specified dates. JSCalendar provides a comfortable interface for entering dates.
* Authorship module enables site admins to alter the “submitted by” field of a node.
* Reptag (Rep[lacement]Tags) module allows you to define tags (like $MYTAG$ or {DATE}) and replace them with user-defined text, images, code, … or use RepTag to format your pages with simple markup-style tags.
* The Comment Mail module allows an e-mail to be sent to the site administrator(s) when new comments are posted. A link in the email allows quick approval, editing, deletion, and/or banning of the poster’s IP address (good for spam).
* Ad module is an advertising system for Drupal powered websites.

Images

* Image module allows images as node types. It’s the basic image handling module, but there are alternatives.
* Image assist module allows easier uploading and attaching images to nodes. Good for non-tech people.
* Image filter allows users to reference images from other nodes. (There are more image filter modules, seemingly doing the same thing.)
* Imagecache is useful for scaling and cropping images, and also caches the different image versions. This one is quite powerful, particularly if your site depends on images of certain formats.
* Upload image takes uploaded images and copies them to image nodes.

Rich media content

* Video provides the ability for users to add video content. To achieve better performance for site, store the video files at third party site and hence share the traffic with other third party sites like YouTube, Google Video, Amazon S3. Only development version can be used with Drupal 5.
* Audio module allows a user to create a new audio node type. An audio node lets you upload, stream, and download audio files, and uses the getID3 library to read and write ID3 tag information from the audio file. It comes with a handy flash player that can be embeded in your site. Useful for podcasts.

Miscellaneous

* Global redirect redirects from old url aliases, which is good both for visitors and search engines (since search engines don’t like to find the same pages on several url’s).

Search 404: If an url doesn’t exist, Search 404 makes a search using the terms in the path and presents the result to the visitor. If there is only one page hit, Search 404 can optionally take the visitor to that page directly.
* Service links module enables admins to add links to a number of social bookmarking sites, blog search sites etc. Includes sites are del.icio.us, Digg, Reddit, ma.gnolia.com, Newsvine, Furl, Google, Yahoo, Technorati and IceRocket.
* Usernode tries to make users nodes. It cares for automatic creation and deletion of a node for each user, the so called usernode. See also Node Profile module for a useful complement. (I understand there is quite a debate on whether users should be nodes or not.)
* User Points provides the ability for users to gain points when they do certain actions, such as posting a node, commenting, voting, inviting friends to the site, etc.
* Workflow-ng allows one to customize Drupal’s built in workflows in a very flexible way. This includes flexible publishing workflows, creating custom redirections, etc.
* Localizer module allows changing and customizing language used in Drupal.
* Contact Link module provides a “contact the author” link for nodes and comments. The link is configurable by node type.
* Backup module allows you to download a backup of your Drupal DOCUMENT_ROOT and database over the web.
* Nodeformpopup module provides popup windows and bookmarklets to submit new nodes with ease. Useful to comfortably add online resources (such as contacts, press releases or articles) into a workflow. Use together with Node form template.

Other resources with similar content

* “What modules do you find invaluable that people don’t know about?”
* “Top 40 projects”: a podcast episode by Lullabot listing some great modules. Skip the first 16 minutes to go directly to the top 40 list.
* “Essential modules”: a podcast episode by Lullabot, recorded during Drupal 4.7. Skip the first 41 minutes if you want to dive directly into the essential module-talk.
* Top 12 modules for search engine optimization: a podcast by Sprydev.

Not high-rated modules

To keep the list above as concise as possible, modules that can be replaced, are deemed less useful, or only useful to a very few newspaper sites are put under this header as a separate list.
If you feel that a module should be moved to this list, please put it under this header along with a comment on why it isn’t high-rated. (If this list becomes too long, it will turn into a separate wiki page.) You are also welcome to comment on modules in this list - if they should be removed completely or put back in the high-rated list.

* Peek allows the creation of links that displays nodes to users who normally do not have access to the node. For example useful in newsletters referring to restricted article no

des. (It appears to have some security risks, though.)

Less useful because of security issues.
* Xstatistics is a module meant for extendibility. It offers basic statistics summaries at the moment.

This module appears to have stagnated.
* Image pager allows neat switching among images in a gallery with prev/next links.
This might be nice if you’re doing an image slideshow, but not really a main function for a newspaper site.
* Remember me module allows users to have persistent sessions via a checkbox on the login form.

This feature doesn’t seem very useful, since remembering username and passwords are supported in most browsers anyway.
* The e-publish helps organize a group of nodes into a publication, such as a newspaper, magazine or newsletter.

Less useful since the organizing is rather unflexible, and can be more custom-made through views and taxonomy.

Discussions about this page

*

request: can someone pack all this thing into one download with drupal installation profile so that anyone can very easily install everything at once. tia.
I don’t think it’s advisable to install all these modules - it would eat too much memory, and double several features. I’ve added links to the modules instead, to make it easier to install them yourself. //Itangalo
*

This page will soon need some kind of cleanup. Please help moving not high-rated modules to the separate list far down on the page (as well as making positive comments to modules that belong in the high-rated lists).

Unix/Linux interoperability components in Windows

Tech Note #1 in the “Interop Components in Windows” seriesDownload Tech Note

By Rodney Ruddock (Interop Systems)

The split-up of Windows Services for UNIX into individual components in Windows Server 2003/R2 and Windows Vista has left users confused as to how to set up the ultimate Unix/Linux interoperability environment.
Whither Services for Unix (SFU)?
Way back in 1999 when Microsoft acquired Interix from Softway Systems many people predicted that Interix would get buried by the Windows people. After all, Interix is a Unix system to be run on the Window OS! Conspiracy theorists were having a heyday.

It took a few years before Services for Unix (SFU) version 3.0 was released with Interix, NFS client, NFS server, User Name Management (NIS) and NFS Gateway to provide a comprehensive Unix solution on the Windows OS. SFU 3.5 was the next release with even more functionality. For many people the 3.5 release was very exciting because SFU became freely available for everyone. Clearly Interix and SFU were not getting buried. Microsoft was not only keeping SFU going, but was improving and expanding it. The additional Unix functionality was also getting more and more popular with IT departments working in a mixed OS environment.

Then Microsoft announced that most of the components of SFU were being integrated into the Windows OS releases. Not only is it all free, but available as part of the base installation of Windows. This started with the release of Windows Server 2003/R2. Of course it meant that SFU would have no more releases as that would be redundant. SFU 3.5 is still available as a free download (for Windows XP, Windows 2000 and Windows Server 2003 pre-R2 users) until 2009 with support continuing until the year 2011.

It’s not so much that SFU has become end-of-life, but that it has been allowed to advance to the next level. By being part of the Windows OS release everything that was SFU should now be taken even more seriously. With the recent release of Vista the components can be found in the Ultimate and Enterprise versions. The upcoming Windows 2008 Server release will also have all of these features.

Being integrated into the Windows OS release meant some name changes for some of these features. NFS client and server are still NFS client and server. User Name Mapping has been renamed Identity Management. Interix now goes by the moniker SUA (Subsystem for Unix-based Applications) but the system will continue to identify itself as “Interix” for clear compatibility with programs, scripts and makefiles.
Installing SUA, NFS, etc. on Windows OS
To install any of these components/features on Windows 2003/R2, Vista or Windows Server 2008 Beta is very simple. No extra CDs or DVDs are required. From the Control Panel start the “Program and Features” application (formerly known as “Add/Remove Programs”). Then select from the left panel “Turn Windows features on or off.” After a few seconds a popup window will list all of the currently active features. Scroll through the list to make sure the features you are interested in having active are checkmarked. Some of the features are only available on the Server versions. Here’s the list as it appears on Vista:

*
Services for NFS to install NFS client and matching administrative tools
*
Subsystem for Unix-based Applications for SUA/Interix

Here’s the list as it appears on Window 2003 R2. The selection is more awkward on R2 for most items. For SUA the selection is the same as with Vista. For the other components you need to select “File and Print Services” to get the next submenu:

*
NFS Admin
*
NFS Client
*
NFS Server
*
Server for NFS authentication
*
Identity Management for Unix (IdMU)

Once these features have been installed you will need to reboot the machine. After the reboot you will have some configuration to do that will vary depending on which features you chose. If you chose SUA then you will need to download the Utilities and SDK package to get the shells, utilities, libraries and manual pages. This can be done easily from the Start Menu under All Programs, Subsystem for Unix-based Applications.

When you install NFS Server it is always recommended that you install Identity Management (formerly known as User Name Mapping; UNM) so that Windows IDs can be mapped to Unix IDs and the reverse.
What is Interix/SUA?
Interix is the Unix-like system that runs on the Windows OS. It runs as a peer system to the Win32 environment that most people simply call Windows. Interix has the same access to the NT kernel, the file systems, networking and security systems that Win32 does.

The development of Interix began in the early 1990s with Softway Systems under the product name OpenNT. Softway developed the Interix system and utilities with the goal of meeting the Unix specification and defacto standards. While Microsoft had originally developed a strictly POSIX compliant system for NT 3.0, it lacked utilities and many supporting features needed beyond POSIX to make a Unix system. Examples of de facto standards that are incorporated into Interix are Berkeley sockets and pseudo-terminals. Other standards included the X/Open standards (e.g. XCU) and matching test suites.

The resulting environment of functionality meant that when you logged into an Interix system by, for example, telnet, the shell and utilities gave the same feel as running on a BSD based system. With over 350 utilities plus the SDK for developers covering X-Windows, Motif, OpenGL, libc, etc. Interix became another Unix-like platform that Unix software could be ported to.

A big win is that it’s on the same machine that’s running Win32. This means that on one machine Win32 and Unix applications can run side-by-side. Cut and paste from an X-Window to a Word document with ease. Collect input from a Win32 program and analyze it with a set of Unix tools – or the reverse. One of the early examples of inter-system communication used the Unix ‘tides’ program to generate information placed into an Excel spreadsheet.

For administrators this gives them the ability to have a common base of tools and functionality available across a heterogeneous computing environment. Connecting by telnet or ssh to and from all machines is good. Even better is being able to run the same scripts on Interix as on Solaris or Linux to complete a task. No more getting bogged down in a GUI or wasting time repeating tasks that can be automated in scripts.
What is NFS?
NFS is the Network File System developed by Sun Microsystems in the 1980s for sharing disk drives across a network. It was developed for use with Unix systems. It also became a de facto standard at many sites for providing network disks to PCs as well. NFS has an excellent track record for network drive access as well as management of these resources.

Meanwhile on Windows, SMB evolved (now called CIFS) to be a de facto standard for Windows machines. It has some shortcomings that have never been addressed. The advent of SAMBA (on Unix) was an attempt to bridge SMB shared disks to Unix machines. However, SAMBA cannot overcome the shortcomings of SMB. A couple of these shortcomings include the lack of case-sensitivity in file and directory names, and inconsistent file information. These shortcomings make it difficult to use SMB in a mixed OS environment. On the other hand, NFS has shown itself to work better in this mixed OS environment.

Coupled with the use of NFS on Windows is User Name Mapping (UNM). This allows the mapping of Windows Security IDs to Unix IDs both to and from Windows. By doing this the Windows system communicates
with the Unix system in the same, common language for security access to the files. The mapping of the IDs can be done in a simple manner and also in more complex arrangements with multiple systems. Without UNM the access to the disks must be done in an anonymous mode that gives a reduced security for the shared disks.
Starting with Windows Server 2003/R2 the UNM became part of Active Directory rather than as a stand-alone service.
Identity Management for Unix (IdMU)
Identity Management for Unix (IdMU) is a merging of what was previously known as Server for NIS (Network Information System) and User Name Mapping (UNM). Starting with Windows Server 2003/R2 this is integrated with Active Directory (AD). This allows for the control of NIS domains from a Windows machine. IdMU does not allow for a Windows machine or an AD domain to be placed under the control of a Unix NIS server though. Included with IdMU is Password Synchronization to allow AD and NIS to coordinate password updates for more uniform user control in a heterogeneous environment.

With IdMU the network of machines with a heterogeneous mix of operating systems can have a single list of users that have the same password to access all of the machines. It also means that users can change their passwords on any of the machines and have the result reflected in all of the other machines on network. The resulting ease for users and system administrators makes with this a win-win tool.

The identity mapping capabilities provide the SID to UID mapping for NFS communications.

For more detailed information there is a separate Tech Note written about installing and configuring IdMU.
Setting up a Working Environment with SUA/Interix
With SUA/Interix installed as one of the additional Windows OS features the next order of business is to install the commands and utilities for command line usage. At the same time, optionally, the Software Development Kit (SDK) can be installed if you will be doing software development. From the Start menu, under All Programs then under Subsystem for Unix-based Applications you can find the link that will automatically retrieve the commands and SDK from the Microsoft web site.

When doing the installation there is the option of working with the default installation or using a custom installation. The custom installation gives you the best selection for what to install or not install without a lot of complication. For strictly command line usage the installation of the “Base Utilities” and “GNU utilities” together gives the widest set of programs. The “SVR5 Utilities” are based on the Unix System V utilities and are not as commonly used unless the site has a strong System V emphasis already. The Base and GNU utilities provide the programs with options that most Unix and Linux users already will be familiar with.

The SDK, similar to the utilities, has two selections: “Base SDK” and “GNU SDK.” The Base SDK is a must for developers to install because this provides all of the needed include files, SDK manual pages, static libraries and utilities for building applications. The Base SDK includes wrapper scripts (c89 & cc) to work with Microsoft Visual Studio’s C/C++ compiler (MSVC). It’s recommended to have MSVC installed before installing the SDK so that the SDK sees MSVC and does some automatic configuration. The GNU SDK will install the gcc compiler suite (which includes g++) and shared libraries. With gcc you will be able to create Unix-style shared libraries. Included are the X11 libraries used for creating Unix GUI applications.

If you run into any difficulty installing SUA, you can refer to the second Tech Note titled Installing SUA Commands, Utilities and Libraries where step-by-step screenshots are included.

For both users and developers additional programs and libraries from the F/OSS world are desired such as bash, OpenSSH and an X-server. These items don’t normally ship with SUA/Interix. However, they can easily be obtained from third-parties at several different levels (free, low-cost and premium) depending on the application. One of the key sites for getting these third-party programs is the 12,000-member Interop Community website where many applications have been prepared in ready-to-go binary packages (for more details visit the site www.interopsystems.com/community). This site is operated independently by Interop Systems, with a financial contribution from Microsoft.

For the best results in application operations and security some key choices at installation should be made. During the installation phase you should choose, when asked, to have case sensitive pathnames turned on and the SetUid ability also turned on. For case-sensitive pathnames there are some key things to note:

1.
Turning this setting to “on” will only affect SUA/Interix. It will not affect Win32.
2.
All Unix applications expect a case-sensitive environment. Best behavior from your Unix applications happens with case-sensitivity on.

The SetUid ability is the special ability on Unix systems to have certain applications run with the authority and privileges of a specific user – usually the owner of the application. This is a very powerful ability. And with great ability comes the responsibility of being careful to not create a security problem. The tremendous, positive results of having this ability easily outweigh the responsibilities in the vast majority of situations. SetUid allows for the Administrator (and only the Administrator, not members of the Administrators group) to get certain special tasks done quickly and easily at the local machine or through a remote connection such as telnet or ssh. Also, it allows for the automation of many tasks in the background on behalf of the users. An example of this is setting up automated tasks with the cron utility.

The overall footprint of a full installation plus several dozen third party applications is relatively small by today’s terms. A full install includes all user applications and SDK programs, files and libraries is less than a full CD. That’s a tiny amount of disk space these days. So there’s little worry about filling a disk if you want to install everything. Installing everything provides pretty much the default installation on most Unix-like systems.

One of the best and highly recommended things to do is to explicitly set a home directory in the user database for each user. This provides the highest amount of security for users for their files and for applications that need ensured trust when running. When users do not have an explicit directory in the user database (Active Directory is an example) then spoofing and Trojan Horses can be easily done. There are also applications that need to know that the user information they get is 100% trustworthy. A key example of this required trust are the SSH applications. Public keys must be stored on an individual user basis – sharing is not a secure option. Individual home directories, with correct file permissions, provide the ability to store this information. Obtaining the location of the users’ home directories from the trusted user database where the information is stored is critical to security. If the chain of trust cannot be assured then trust cannot be ensured and the security-base applications refuse to work.

Of course the mark of good administration is one that automates as much as possible. If it’s a large task or a task that gets repeated more than once then scripting the job is the way to go. The setting of user home directories in the user database can be automated. Adding new users from a list can be automated. The scripts can be done in a variety of scripting languages such as shell, Perl, Tcl, PHP and Python. The available scripting choices make it easy to get a script done because a new language does not need to be learned. Having familiar tools available on SUA/Interix that work and behave as on all other platforms is central t

o making things easy for IT shops in a heterogeneous computer environment.
Setting up NFS Server
Having NFS working with or without SUA/Interix installed is a plus in a heterogeneous network of machines. This common file access method is fast for the users and easy to setup by the administrator. There are two halves to the NFS setup. There is the server-side, where the disk lives, and the client-side, where the access requests will come from.

The server-side of NFS can come from a Unix machine or from Windows machine providing NFS. To NFS clients on the network either of these types of NFS servers will appear virtually indistinguishable. If it provides NFS services then the NFS client will be happy. For a Unix machine providing NFS services, refer to that machine’s NFS server documentation. For the Windows NFS server the vast majority of installations can happen with straight-forward instructions. Actually it’s prudent to mention that this information is available with the on-line help too. As mentioned earlier the NFS server component will be installed from the list of Windows Features via the Program and Features on the Control Panel.

From a Windows machine hosting NFS Server the simplest way to share a disk is to start Windows Explorer. Then choose the disk or directory that you want to share by NFS Server. Right click your selection to open the Properties panel. Then choose the NFS Server tab. Now enter a name that the NFS share will be known by for any NFS clients and apply this setting. You may optionally want to allow anonymous access to this share.

For users to access this NFS share two additional actions must happen. One action, described in the next section, is the NFS client must mount the share. Action number two is the user’s identity must mapped. As mentioned earlier this identity mapping used to be known as Username Mapping (UNM). Starting with Windows Server 2003/R2 this mapping is part of Active Directory. A later section outlines the name mapping.
Setting up NFS Client
Installing the NFS Client side is, without surprise, done through the Windows Features list via the Program and Features application launched from the Control Panel. Scroll through the features list and make sure NFS Client is checked. This installs an NFS Client driver on the machine. This client driver handles the communication to the NFS server and also handles presenting the NFS disk to the local system like it is just another disk.

Before mounting an NFS disk to a client it is recommended that you configure the identity mapping for the client-side. The NFS client-side can use the older User Name Mapping (provided with SFU) or use AD (starting with Windows Server 2003/R2 and after). A special administrative panel is used for the mapping configuration. From the Control Panel you select Administrative Tools and then select “Services of Network File System (NFS)”. A new panel will open from which you select “Client for NFS” and open the properties for it (by right clicking the mouse). From here you choose to use AD or UNM or both for the mapping.

Mounting, or connecting, an NFS disk from an NFS Server is done in the same manner that a disk from a Windows machine is mounted. From a Windows Explorer Tool menu select Map Network Drive. As normal, you can enter the details directly if you know them or you can browse with a GUI to get the right NFS disk to be mounted. And without any more fanfare the job of getting an NFS disk mounted is done.

Alternatively, if you wish, you can mount NFS disks using command line utilities. More information on this is provided with the on-line help.

Ideally the user using the NFS disk is accessing the data on that disk as that user. That happens with user information being transmitted between the NFS client and the NFS server. Between machines the identity of some of the users may vary somewhat resulting in the NFS server not recognizing the user. In this case it is typical that access to the NFS disk will be provided, but the user will be making each access request as an anonymous user. This makes it difficult for users wanting to write data or read data that has even a mild amount of permission restriction. The solution for this is to have the identity mapping configured (what used to be called User Name Mapping). This maps user identities on the NFS Client machine to appropriate user identities for the NFS Server machine resulting in the expected rights for data access. If you do decide that you want to have user access as an anonymous user you must specifically set this as allowable with the NFS Server since, for security reasons, this access mode is typically not allowed by default.
Name Mapping Outlined
Name Mapping allows for the mapping of a user identity in one domain or on one machine to another user identity that is recognized on another machine. This provides a key element with NFS disk support particularly critical in a mixed OS environment.

Windows OS machines use SIDs (Security Identifiers) for user and group identities. Unix machines use UIDs (User IDs) and GIDs for user and group identities respectively. NFS Server and NFS client communicate using UIDs and GIDs. This is based on the original design of NFS working with Unix machines. Thus sending SIDs from an NFS Client to an NFS Server is not going to work with the protocol. The mapping of a SID to a UID or GID is performed in a manner that is seamless to NFS and to applications.

Starting with Windows Server 2003/R2 an LDAP store (such as Active Directory) that is RFC 2307 compliant can now be consulted to get the mapping to UIDs and GIDs. Previously the mapping was done with UNM. The NFS clients can use either or both mapping providers as described in the section above “Setting Up NFS Client.”

Configuring the mapping on AD requires the administrator to add a specific mapping identity for each user. This is done through the Identity Management feature which also handles the NIS integration. Through AD a user is chosen and the Properties panel is opened at the “UNIX Attributes” panel. In the UID box new user ID is entered. This value is what will be provided to the NFS client when asking for a SID to be mapped to a UID. The NFS communication will use this UID value. The NFS Server in turn will get this UID mapped to a SID when it receives the NFS request. The reverse happens when the server sends responses to the NFS client.

The component UNM is no longer available after SFU 3.5 because the ability of NFS to map the identities is now being provided by any RFC2307 compliant LDAP such as Active Directory. In fact you can do this with Windows 2003 Server R2 too. But for Windows XP and Windows 2003 Server pre-R2 the UNM services must be used. The NFS client with Vista is flexible enough to use one or both methods.

Feel free to post your questions, comments or corrections in our Interop Community forums.