Linux: Kickstart Process

A quick summary of Linux's automated install process called 'Kickstart':

-'live cd' allows you to run the os without actually installing it on a local disk.
-it runs in memory within another host os.
-interactive installation on local system has its limits--it is error prone and tedious.
-network installation helps answer some of the limitations of interactive installation.
-in network installation:
    . dhcp (or tftp) is used to boot local system (though it doesnt have install media)
    . then installation files from a network server are retrieved using http, ftp or nfs.
-network installation is appropriate for sites with more than 10 systems.
-network installation is possible because of the abilities of network card to bypass os to go to the network.
-this uses the 'Preboot eXecution Env' (PXE) standard of Intel platform.

-kickstart is Redhats tool for automated installation.
-it is really just a scripting interface to the redhat installator - Anaconda.
-kickstarts behavior is controlled by a single config file, generally called ks.cfg.
-this file can be edited in a text editor or via the gui tool system-config-kickstart.
-kickstart config file has three main parts:
    . the command section    - specifies location of install files, language, keyboard, timezone etc.
    . the package section    - specifies pkgs to install; starts with %packages directive.
    . the custom  section    - specifies shell scripts to run pre or post install (if your site has any)
-kickstart expects its installation files to be laid out as they are on the distrib cd.
-this means packages to be in the dir RedHat/RPMS.
-once ready, you boot with an install disk and type 'linux ks' at 'boot:' prompt to specify the ks.cfg file.
-your system then figures out n/w addr using dhcp and tries to mount the boot files using nfs.
-alternatively you specify the ks.cfg on a n/w server.
-eg:    boot: linux ks=http:server:/path
-this tells kickstart to download boot files using http instead of nfs.

Linux: System Logging

Today we discuss System logging tools available in Linux..

-syslog    - an integrated system for log management.
-usually a log entry is a single line of text.
-the same file has entries from multiple sources.
-eg: two consecutive lines might be from totally different events.
-usual location of logs - /var/adm or /var/log.
-usual owner of logs is root.

-/var/log/wtmp contains login,logout info in binary format
-to read it simply type 'last' or 'lastlog' without any parameters.

-syslog consists of three parts:
    . syslogd    -the syslog daemon - /etc/syslog.conf
    . openlog    -library routine that submits msgs to syslogd
    . logger    -user level cmd that submits log entries from shell
-syslogd is started at boot time and runs continuosly. cant be managed by inetd.
-programs send their mesgs to a socket file /dev/log.
-syslogd reads this file /dev/log and routes the msgs to appropriate log files.
-a hangup signal (HUP 1) causes syslog to close its logs
-a TERM signal causes syslog to exit
-syslog pid is stored in /var/run/syslogd.pid
-syslog config file /etc/syslog.conf has the format:
    . service.level  <tab> action            [tab is must, spaces dont work. cause errors]
-eg:      mail.info    /var/log/maillog
      mail.emerg    /var/log/messages
-highest level is 'emerg'. lowest level is 'debug'.
-syslog allows remote logging -ie sending log entries to a remote logging server.
-note:     if a service is repeatedly referring syslog messages --it can cause denial of service.
    linux reduces this risk by not accepting syslog msgs from remote machines unless with '-r' or '-h' flag.
-if the remote logging server is down, the log entries are irretrievably lost.

-alternates to syslog - syslog-ng, rsyslog, sdsc secure syslog etc..

-challenges in kernel logging:
    . to create permanent record of boot process without depending on any fs.
    . becoming independent of any process/daemon or their loggings.
-dmesg answers the above. it even contains messages generated before init begins.
-dmesg does this by logging the boot messages in a buffer before writing to its log file.

-kernels ongoing logging is handled by a daemon called klogd. it is a superset of dmesg.
-klogd reads kernel buffer and passes them to syslog which stores them in /var/log/messages of /var/log/syslog.

-all boot messages are always sent to the console.
-if they are an annoyance, then after booting, they can be subdued like this:
    # sudo dmesg -n 2            level 1 (panic) to level 7 (debug)

Linux: Disk Storage Basics

Today we discuss some basics of storage management in Linux:

-to add disks to a system:
    . attach the disk to the system physically
    . fdisk -l to list the disks and identify the new one.
    . fdisk or parted to partition the new disk (or use it as a whole)
    . mkfs  -t to format the partitions and create filesystem
    . mount -t to mount the fs
-even in the case of disk failure, the hardware and firmware on the disk usually remain operable. only the platters corrupt.
-in other words it is still possible to access data.

-For traditional hard disk storage devices, sequential data transfer rates are higher than actual random read-write speeds.
-eg if a disk is rated at sequential transfer rate of 120MB/s, it is not the actual speed you get in reality.
-actually it is rare to get a read/write speed of 2MB/s.
-By contrast, solid state drives routinely produce random read write at 30MB/s or higher.
-Examples of storage hardware interfaces - ide/pata, sata, scsi, fiber channel, usb -- ide, sata and scsi are most common.
-traditionally scsi has been the earliest and yet the best performer. Now a days, sata is comparable.

Next up, file system basics...

Linux: User Managment Tips

Without going into the details of commands and syntax, here are some helpful points to remember about user management:

-/etc/passwd is afterall a database for small or standalone systems.
-Directory services (eg nis, ldap) replace it for user mgmt in bigger installs.
-/etc/passwd has seven colon delimited fields for each line entry.
-passwd encryption algorithms are set in /etc/login.defs file. the default algorithm is called 'crypt'.
-this file (/etc/login.defs) also sets the password policy (eg length, age, expiry etc).
-if you put a * or an x in the password field in /etc/passwd, it forces new users to set a passwd at first login.
-never ever leave this field empty--big security hole.
-if you have a fake login shell in the /etc/passwd file (eg /bin/false) then login as that user is not allowed.
-bash is from gnu.
-when people leave an org, it is not a good idea to recycle uids. bec if you restore from backups, wrong uids will be restored.
-uid and gid are 32 bit integers.
-the default gid is not used to determine access (unlike uid), it is only used during new file/dir creation.
-if home dir field is empty in /etc/passwd, it puts user in /. but if /etc/login.defs sets default_home=no, login is disallowed.
-before creating users on a system, get people to read, sign and date user agreement/policy docs.
-To create users in bulk, linux provides the utility called 'newusers'.
-To lock accounts usermod -L; to unlock accounts usermod -U.
-The -L puts an '!' in front of the encrypted passwd in /etc/shadow, -U removes it.


-Microsofts Active Directory is based on ldap and kerberos. it tries to be the boss in a heteregenous env.
-in heterogenous env having msft and linux, active dir is easier to be set as the primary and linux ldap dbs as secondary.
-several opensource sso systems exist like josso, cas, likewise open etc.

Linux: Access Control Basics

-accounts vs access control:
    . accounts are for individual users and define set of possible operations for that user. (eg what operations can user A do?)
    . access control system is a set of potential user/operation pairs (eg can user A do operation x?)

-access control can be built into the kernel or into the file system. the former being the default.

-the defining characteristic of the root user is uid of 0.
-while it is possible to change the root user name or create additional users with uid 0 -- but that is a security risk.
-superuser is defined as the user with effective uid 0. the actual user name is root.
-superuser (ie proc with effective uid 0) allows itself to change its uid and gid.
-but once it assumes another uid,gid it cant go back.
-this happens for example in the login proc that starts as superuser but then becomes the uid,gid of the user that logs in.

-setuid, setgid based access control allow executable files to run with elevated permissions.

-Access control (kernel/fs) types:
    . role based     (rbac)    -  assign privs to roles and roles to users.
    . mandatory     (mac)    -  like selinux - prevents users from delegating access to their objects.
    . pluggable    (pam)    -  answers questions like 'is user x really x?'
    . kerberos        -  pam defines the framework, kerberos defines the implementation, esp on remote hosts.
    . filesystem    (acl)    -  traditional acl based on user, group ownership.

-root login does not keep a log of actions. if multiple people have root access, one cant tell who logged as root and when.
-a slightly better way to log root is 'su'. It does not record the commands executed as root, but tells who became root and when.
-su is best reserved for emergencies.
-a still better way to log root is 'sudo'. sudo keeps detailed logs of actions, hosts, time stamps etc.
-using sudo means you can have only few or zero people with access to real root.
-sudo is faster than su and direct root login. also a single file can be used to control access for an entire network.

Linux : Boot Process

-Bootstrapping
    . is the process of starting up of the computer
    . the computer starts itself, as the OS is not yet available at this stage.
    . like a sleeping hiker who wakes up and pulls himself up with his own boot's straps, without external help.
    . at a macro level, during bootstrap, the kernel is loaded into memory and begins to execute.
    . at a micro level, during bootstrap, the boot code (BIOS) in ROM is executed foll by search, load & exec of kernel code.
    . the search for the kernel requires knowing disk geometry. this is the info in the mbr that lives in 1st block of disk.
    . usually the kernel resides in /boot/vmlinuz.
    . once the kernel is running, it probes the hardware and starts the first process called init (pid = 1).
    . after this, init starts subsequent processes, daemons and mounts filesystems.
    =>     Boot strap = BIOS > kernel > init > daemons     

    . If for some reason, the system can not complete the above steps (eg a damaged filesystem), then maintenance is reqd.
    . To do this sort of maintenance, linux has the foll mode:
        -maintenance mode a.k.a     recovery mode    a.k.a    single user mode.
    . in this mode, network access is not allowed and physical access to the system is needed.

-Two stage boot loading process:
    . stage 1 - ROM BIOS code executes, locates mbr and loads bootloader into memory from disk.
    . stage 2 - bootloader locates and loads kernel.
          - kernel scans memory, creates memory area for system and user procs, prints memory details on console.
          - then kernel then starts init. init lives in the user space.
          - init then spawns other subsequent process and this completes the boot process.

-Once the BIOS has figured out which device it has to boot the system from, it searches the first block on that device.
-This first block is 512 bytes in size and is called MBR.
-The MBR tells the system where to look for the secondary boot program called the 'bootloader'; eg: grub.
-this bootloader then loads the kernel.

-GRUB was developed by GNU. Ships with most linux on Intel platforms.
-grubs job is to choose a kernel from a previously assembled list and load it.
-grub config file location is either /boot/grub/grub.conf or /boot/grub/menu.lst depending upon the system.

-In a multiboot system, each disk partition can have its own bootloader. but the system can have only one mbr.
-so when setting up a multiboot system, it is required to specify which of the partitions is the 'master'.

-the single user mode is not a real init state. It is an intermediate step to init 1. Its job is to prompt for root passwd.
-when the system is started from init 0, it reads inittab and runs the scripts for the default level.
-when the system is already started and init n comand is issued, the init state is changed to n.
-internally this is done using telinit cmd (ie to go from init n to init m: init n -> telinit m -> init m).
-telinit -q cmd forces init to re-read inittab file.
-system  startup scripts live in /etc/rc.d dirs.
-service startup scripts live in /etc/init.d dir. These scripts allow user defined services to be started & stopped.

-shutdown halt does these:
    . logs the shutdown
    . kills non essential procs
    . executes sync system call
    . waits for fs writes to complete
    . halts the kernel

-reboot is identical to shutdown except that it restarts the system.