Wednesday, January 26, 2011

The Linux boot process, a chart - SysAdmin1138 Expounds

The Linux boot process, a chart - SysAdmin1138 Expounds
BIOS
EFI
  • POST
  • Read bootable media
  • Load Master Boot Record
  • Execute MBR
  • POST
  • Read bootable media
  • Load the GPT table
  • Mount the EFI system-partition
  • Run EFI-specific code
GRUB(v1)
GRUB(v2) (E)LILO
  • Stage 1 loaded into MBR/EFI and gets executed by BIOS/EFI
  • Stage 1.5 loaded by Stage 1, including critical drivers
  • Stage 2, in the boot filesystem, executes
  • Stage 2 loads the kernel
  • Stage 1 loaded into MBR/EFI and gets executed by BIOS/EFI
  • Load first sector of core.img
  • Continues loading core.img
  • Loads GRUB config
  • Loads the kernel
  • Stage1 loaded into MBR (or EFI by ELILO) and executed by BIOS/EFI
  • Stage2 is leaded by Stage 1, executes
  • Loads LILO information.
  • Loads the kernel
Kernel Load
  • The kernel uncompresses into memory
  • If configured, the kernel mounts the Initial Ramdisk, which contains needed modules to load the rest of the OS
  • Mounts the root filesystem, loading any needed modules from initrd
  • Swaps / from initrd to the actual root filesystem
  • Executes the specified init process
Initd
Systemd
Upstart
Launchd
  • Is launched by the kernel as PID 1
  • Checks /etc/inittab for loading procedures
  • Runs scripts specified by inittab
    • Mounts needed filesystems
    • Loads needed modules
    • Starts needed services based on runlevel
    • Finishes setting up userspace
  • Is launched by the kernel as PID 1
  • Reads /etc/system.conf
  • Mounts needed filesystems
  • Loads needed modules
  • Starts services as needed
  • Is launched by the kernel as PID 1
  • Runs startup events listed in /etc/events.d based on runlevel.
  • Loads needed modules
  • Mounts needed filesystems
  • Starts needed services
  • Is launched by the kernel as PID 1
  • Reads /etc/launchd.conf for config details
  • Reads /etc/launchd.plist for per-driver/service details

Tuesday, January 11, 2011

How I '”usually” bypass transparent content-filters (for troubleshooting purposes)

In my work, transparent content-filtering devices usually throws a (transparent ?) spanner into my troubleshooting work. This usually could be in the form of IPS/IDS devices or transparent proxies. It’s there, happily doing its thing, but quite invisible from end-point device’s perspectives.

My favourite tool in this situation is SSH and its port-forwarding functionality.

Since tunelled traffic is encapsulated and encrypted in SSH transmissions, these pesky transparent device wouldn’t know any better but to allow them through; however, always double-check your Firewall/IPS configurations that it DOES NOT block SSH (default TCP/22) traffic in the first place. Take the following scenario where normal traffic is being (transparently) intercepted and certain policies are applied.

image

This is what SSH and its port-tunnelling accomplishes:

image

It pays to have the endpoint devices to be able to ‘talk’ SSH to have the above to work though. The OpenSSH client on *nix systems or Putty on Windows should work perfectly well as the client.

However, native OpenSSH daemon (as the SSH server component) is not easily available on Windows system (in cases where both endpoints are Windows systems). Have a try at freeSSHd, a Windows implementation of SSH server component; it’s easier than trying to run a Cygwin implementation of sshd.

Thursday, January 06, 2011

Updating Sendmail access file (Revisited)

Sendmail access file format for IP addresses is based on full octet wildcards. for example:

  • 10 represent 10.0.0.0/8
  • 172.16 represents 172.16.0.0/16 (sorry, /12 is not available)
  • 192.168.100 represents 192.168.100.0/24

A sample of Sendmail’s access file (normally located as /etc/mail/access) is as such:

10                     RELAY
172.16                 RELAY
192.168                RELAY
mydomain.com           OK

After editing the Access file, remember to:

1. Run makemap to create/update the access database read by Sendmail from the edited text Access file.

"makemap hash /etc/mail/access < /etc/mail/access"

2. Restart Sendmail

"service sendmail restart" OR "/etc/init.d/sendmail restart"

Wednesday, January 05, 2011

NetBIOS-ssn issue when a naming collision/conflict is detected

I encountered an issue today affecting NetBIOS/CIFS/SMB filesharing, the situation is as follow:
  1. User have one physical Windows 2003 server connecting to a remote CIFS fileserver as mapped drive.
  2. Remote connection is via Firewall and IPS appliances. Firewall only allows TCP/139 outbound, TCP/445 is blocked.
  3. I P2Ved that Windows 2003 server into vSphere
  4. Overall operation of the P2Ved server is OK.
  5. End-user complains that the virtualized server now cannot access the fileshare either directly via UNC or via "net use" command
Unfortunately the end-user did not network-disconnect or powered-off the original physical server, they merely changed its IP address.
 
This causes the broadcast domain to have a NetBIOS name collision, both the old physical and the new virtualized server uses the same NetBIOS name (but with different IP address).
 
It seems that when a NetBIOS name collision is detected on the local host, the host refuses to use legacy ports (UDP/137, UDP/138 and TCP/139) and only uses TCP/445 for NetBIOS connection.
 
Since the connection to the external fileserver has its TCP/445 blocked by the firewall, and since the new server refuses to use legacy NetBIOS ports, i.e.: UDP/137, UDP/138 and TCP/139, the filesharing fails.
 
Any of the method below should solve the issue:
  • Shutdown or network disconnect the old physical server, Reboot the new server afterwards or
  • Rename the NetBIOS name of the old physical server and reboot the new server or
  • Allow TCP/445 to destination fileserver (destination fileserver must support Microsoft-DS; Windows 2000 and above).

Sunday, January 02, 2011

How I learned to stop worrying and love the game

Once upon a time there was a Principal who thought oh-so highly of one of its Partner.

The Principal gave them price protection that would enable them to win biddings even if other Partners slashed their margin up to 0.1%.

One day, that preferred Partner lost a bidding to an oh-not so preferred Partner. End of story? Not really.

The not-so preferred Partner requested for a consolation discount from the Principal; anyways, their Product still got sold and the Principal still retained good margin on the Product. Better margin than if the Product was sold along with the protected pricing of the preferred Partner.

Having good relationship with the end-users, the not-so preferred Partner then proceeded to pass the contact details of the end-user to the Principal to plead their case.

The Principal made a big hoo-haa of the oh-not-so preferred Partner NOT doing any groundwork in the project and thus not entitled to any discounts and rather than contacting the end-user, they proceeded to contact the preferred Partner (who lost the bid) and ask regarding the outcome of the bidding.

The clueless preferred Partner informed the more clueless Principal that the project is not yet awarded and the winner of the bid is still not decided by the end-user.

Quite odd as the oh-not-so preferred Partner even attached a copy of the Award letter when requesting for the consolation discount.

Sometimes, IMHO, even FreeBSD jail looks more attractive technically and Xen looks more attractive financially than this virtualization Product carried by this clueless Principal.

And they lived happily ever after..... the end.