android os notes

upgrading old phones to newer OS

http://hardware.slashdot.org/submission/1725958/How-to-Jailbreak-And-Upgrade-Old-Android-Phones

PXE boot notes

pxe boot client
http://www.linuxreaders.com/2010/06/24/pxe-boot-ubuntu-10-04/
pxe boot server (centos version)
http://www.linuxreaders.com/2010/06/15/pxe-boot-server-on-centos/

Client

This works with latest version – ubuntu 10.10.
Once you are done setting-up PXE Server, you might need few OS booting from network / pxe for rescue purpose.
Ubuntu 10.04 can be configured to boot from network & can be used for system rescue.
Following is the procedure to boot Ubuntu 10.04 using PXE.
Mount ubuntu live iso on pxe server
mkdir /mnt/iso
mount ubuntu-10.04-desktop-i386.iso /mnt/iso
Create nfs share for ubuntu & copy all the content of live cd to it
mkdir /nfs-share/ubuntu -p
cp -rfva /mnt/iso/* /nfs-share/ubuntu/
cp -rfva /mnt/iso/.disk /nfs-share/ubuntu/
Enter following in /etc/exports
/nfs-share/ubuntu/ *(no_root_squash,rw,async)
Apply changes
exportfs -rv
Enter following in /tftpboot/pxelinux.cfg/default

LABEL Ubuntu-10.04
kernel /tftpboot/images/ubuntu/vmlinuz
append boot=casper netboot=nfs nfsroot=NFSSERVER:/nfs-share/ubuntu initrd=/tftpboot/images/ubuntu/initrd.lz

Copy initrd and vmlinuz from Ubuntu live cd to tftpboot
cd /nfs-share/ubuntu/casper
cp vmlinuz initrd.lz /tftpboot/images/ubuntu/

Server
This post will be helpful for linux admins who frequently installs diff linux os. PXE boot is one of the best option to start linux installation & for rescue of the other failed systems. we are using CentOS as pxe boot server.
install syslinux & tftp-server

yum install tftp-server syslinux -y

enable syslinux at boot time.

vi /etc/xinetd.d/tftp and change disable to ‘no’
disable = no
service xinetd restart
chkconfig xinetd on

Copy needed files from syslinux to the tftpboot directory

cp /usr/lib/syslinux/pxelinux.0 /tftpboot
cp /usr/lib/syslinux/menu.c32 /tftpboot
cp /usr/lib/syslinux/memdisk /tftpboot
cp /usr/lib/syslinux/mboot.c32 /tftpboot
cp /usr/lib/syslinux/chain.c32 /tftpboot

Create a base directory for images. Create directories for each CentOS release you are supporting.

mkdir -p /tftpboot/images/centos/i386/5.4
cp /tmp/dvd-centos-54/images/pxeboot/vmlinuz /tftpboot/images/centos/i386/5.4/
cp /tmp/dvd-centos-54/images/pxeboot/initrd.img /tftpboot/images/centos/i386/5.4/

Configure dhcp-server. Add this to your existing or new /etc/dhcpd.conf.
Note: xxx.xxx.xxx.xxx is the IP address of your PXE server
How to configure dhcp server on centos

allow booting;
allow bootp;
option option-128 code 128 = string;
option option-129 code 129 = text;
next-server xxx.xxx.xxx.xxx;
filename “/pxelinux.0″;
service dhcpd restart

Create the directory for your PXE menus

mkdir /tftpboot/pxelinux.cfg

Sample config file
vi /tftpboot/pxelinux.cfg/default

default menu.c32
 
 
prompt 0
timeout 50
ONTIMEOUT localboot
 
MENU TITLE PXE Menu
 
LABEL localboot
MENU LABEL Boot From Hard Disk
LOCALBOOT  0
 
LABEL CentoS 5.4 i386 Installer
MENU LABEL CentOS 5.4 i386 Installer
KERNEL images/centos/i386/5.4/vmlinuz
append vga=normal initrd=images/centos/i386/5.4/initrd.img ramdisk_size=32768
 
LABEL CentoS 5.5 i386 Installer
MENU LABEL CentOS 5.5 i386 Installer
KERNEL images/centos/i386/5.5/vmlinuz
append vga=normal initrd=images/centos/i386/5.5/initrd.img ramdisk_size=32768

improvments port for autoconnect cisco vpn

Improving on the Auto-connecting Cisco VPN

http://www2.kaufmanfamily.net:8080/blog/2010/05/improving-on-the-auto-connecting-cisco-vpn

In my first post in this series I described an auto-connecting setup for Cisco VPNs using OpenWRT and vpnc, and in my second post I showed the details of how I did it. To wrap it up, here are some thoughts about future improvements.

One thing that bugs me about this setup is that I hardcoded some IP addresses. This is a really bad idea, in fact half the reason DNS exists is to stop people from doing this. Someday the VPN administrators could decide to renumber their gateway, and then I would have to connect to each and every WRT and update the configuration, or all my customers would be cut off from the VPN.

I could stop hardcoding the VPN gateway pretty easily, by having it auto-update whenever the WRT boots. Look up the correct IP address and write it to /etc/hosts. (You need to be careful not to trigger the VPN autoconnect when you do the lookup, of course.)

The DNS servers are a little harder to fix. To look them up, we need to actually connect the VPN, and then pull out the nameservers that the VPN tells us to use. But this could be done automatically each time the VPN is connected, and it would make the whole setup more robust. Don’t forget to restart dnsmasq after you reconfigure it.

Another thing that bothers me is that there are a lot of gyrations before the VPN gets connected: a packet goes to a private IP address, matches on the vpn_trigger rule, which queues a message for the ulog daemon, which writes to a file, which causes the file to exist, and also causes tail to create some output, which finally causes the script to start vpnc. Whew!

One suggestion is to use inotify to watch the file, which is a good idea but still requires a file. (Also I don’t see inotify in the OpenWRT Kamikaze package list.) Another possibility would be to write a ulog plugin so that I can omit the file altogether. That might make VPN startup quicker, which would be a good thing.

Finally, if a customer wanted it, there are more sophisticated setups possible. It might be useful to connect to more than one VPN (either serially or at the same time), or to have the different LAN ports on the OpenWRT connect to different VPNs. All of these are possible if the scenario warrants it.

What are your ideas?

Auto connect for Cisco vpn via vpnc

How to auto-connect a Cisco VPN with OpenWRT

from DH Kaufman
http://www2.kaufmanfamily.net:8080/blog/2010/05/how-to-auto-connect-a-cisco-vpn-with-openwrt-2

In my last post I outlined a design for auto-connecting Cisco VPNs using OpenWRT and the vpnc client. In this post I’ll share the code, and highlight a couple of details. Finally, in my next post, I’ll share some thoughts on improving these scripts.

This process requires some knowledge about your VPN setup. To keep my post from getting too long, I’m assuming that you know your VPN domain name and IP address range, that you can quickly figure out the IP addresses of hosts and DNS servers, and that you have a working vpnc config file.

The first step is installing additional packages on OpenWRT. You can install these from the web interface, or using opkg install at the OpenWRT shell:

1. vpnc, the Cisco VPN client
2. ulogd-mod-extra, which pulls down the ulog daemon
3. kmod-ipt-ulog, kernel modules for iptables and ulog
4. iptables-mod-ulog, part of the tool for adding rules to iptables

Next, we need to make sure you can always reach the VPN gateway host. So we configure it into /etc/hosts. Look up the IP address (using nslookup, dig, or a similar tool) and add a line to /etc/hosts like:

aaa.bbb.ccc.ddd vpn.example.org


Now that we know we can reach the VPN gateway, we will redirect dnsmasq to always use the internal servers for the VPN’s domain. Look up the domain nameservers using nslookup or dig from inside the VPN, or just look at the nameservers in /etc/resolv.conf when you’re connected from your PC. Then edit /etc/config/dhcp on OpenWRT and add lines like this:

# EXAMPLE.ORG private servers
list server '/example.org/aaa.bbb.ccc.ddd'
list server '/example.org/aaa.bbb.ccc.eee'


Now, we need the script that will manage the VPN connection. Cut and paste this code into /usr/bin/autostart-vpn.sh:

#!/bin/sh
#
# Autostart vpnc
#
# From http://www.kaufmanfamily.net/blog/2010/05/how-to-auto-connect-a-cisco-vpn-with-openwrt
# DHK 4/17/2010

MYPID=/var/run/autostart-vpnc.pid
LOGFILE=/var/log/ulogd.syslogemu
PIDFILE=/var/run/vpnc/pid

is_vpn_connected() {
        connected=0
        if [ -s $PIDFILE ]; then
                ps=`ps | awk -v pid=\`cat $PIDFILE\` '$1 == pid && $5 == "vpnc" { print $0 }'`
                if [ -n "$ps" ]; then
                        connected=1
                fi
        fi
}

# Fill in our PID file
echo $ > $MYPID

# Loop, monitoring the VPN
while true; do
	is_vpn_connected

	if [ $connected -eq 0 ]; then
		# VPN is not connected. Wait for a request, then start it

		# Wait for a log message, denoting that someone is trying to connect
		while [ ! -e $LOGFILE ]; do
			sleep 10
		done
		pkt=`tail -0 -f $LOGFILE | head -1`
		logger "autoconnect[$] connecting due to $pkt"

		# Start the vpn
		date >> /tmp/autoconnect-vpnc.log
		vpnc >> /tmp/autoconnect-vpnc.log

		# Let the VPN settle
		sleep 2
	else
		# VPN is connected. Wait for it to drop, then clean up

		# Wait for the VPN to disconnect
		while [ $connected -eq 1 ]; do
			is_vpn_connected

			# sleep 10 seconds, check again
			sleep 10
		done
		logger "autoconnect[$] disconnected"

		# Clean up route table
		if [ -f /var/run/vpnc/defaultroute ]; then
			outsidegw=`awk '{print $3}' /var/run/vpnc/defaultroute`
			currentgw=`netstat -rn | awk '$1 == "0.0.0.0" && $4 == "UG" {print $2}'`
			if [ "X$outsidegw" != "X$currentgw" ]; then
				if [ "X$currentgw" != "X" ]; then
					route delete default gw $currentgw
				fi

				# Restore exactly what was saved, except vpnc syntax is slightly wrong
				route add `sed -e 's/via/gw/;' /var/run/vpnc/defaultroute`
			fi
		fi

		# Clean up resolv.conf
		resolvconf -d
	fi
done

We’re almost there. Cut and paste the following code into /etc/init.d/autostart-vpn; this is the startup script that creates the iptables rules and starts the last script at boot time. Make sure you edit the script to list the correct networks for your VPN, and check that the locations (hardcoded, unfortunately) for inserting vpn_trigger in the FORWARD and OUTPUT rulesets makes sense:

#!/bin/sh /etc/rc.common<br />#<br /># From http://www.kaufmanfamily.net/blog/2010/05/how-to-auto-connect-a-cisco-vpn-with-openwrt<br /># DHK 4/17/2010<br />#<br /># Start after dnsmasq<br />START=80<br /><br />VPN_NETWORKS="10.0.0.0/8 192.152.0.0/16"<br />EXT_IF="eth0.1"<br /><br />check_firewall_rules() {<br />	trigger=`iptables -L vpn_trigger 2>/dev/null`<br /><br />	if [ "X$trigger" == "X" ]; then<br />		# Fill in vpn_trigger ruleset<br />		iptables -N vpn_trigger<br /><br />		for net in $VPN_NETWORKS; do<br />			iptables -A vpn_trigger -o $EXT_IF --dest "$net" -j ULOG<br />		done<br /><br />		# Hook vpn_trigger into OUTPUT and FORWARD rules<br />		# Ought to do something smarter than hardcoding the position<br />		iptables -I OUTPUT  4 -j vpn_trigger<br />		iptables -I FORWARD 4 -j vpn_trigger<br />	fi<br />}<br /><br />start() {<br />	check_firewall_rules<br /><br />	/usr/bin/autostart-vpnc.sh &<br />}<br /><br />stop() {<br />	if [ -f /var/run/autostart-vpnc.pid ]; then<br />		kill `cat /var/run/autostart-vpnc.pid`<br />	fi<br />}<br />

One detail I skipped last time is that vpnc, as packaged for OpenWRT Kamikaze, will stomp on your resolv.conf file. Its default configuration just doesn’t work on OpenWRT. (The issue is that OpenWRT puts the WAN resolv.conf details in a non-standard place.) There’s an easy fix for this, though. Cut and paste the following code into /sbin/resolvconf. vpnc will find resolvconf and use it to manage /etc/resolv.conf correctly.

#!/bin/sh<br />#<br /># Simple resolvconf manager to integrate vpnc better with WRT<br />#<br /># Update /tmp/resolv.conf.auto, NOT /etc/resolv.conf. This affects the<br /># DNS resolver operation, which is actually the right thing.<br />#<br /># Usage:<br />#<br />#   resolvconf -a [if] < new-resolvconf<br />#<br />#   resolvconf -d [if<br />#<br /># We ignore the [if] argument.<br />#<br /># From http://www.kaufmanfamily.net/blog/2010/05/how-to-auto-connect-a-cisco-vpn-with-openwrt<br /># DHK 4/13/2010<br /><br />BACKUP=/tmp/resolv.conf.bak<br />RESOLV=/tmp/resolv.conf.auto<br /><br />if [ $1 == "-a" ]; then<br />	# Change resolv.conf<br /><br />	if [ ! -e $BACKUP ]; then<br />		cp $RESOLV $BACKUP<br />	fi<br /><br />	cat > $RESOLV<br />fi<br /><br />if [ $1 == "-d" ]; then<br />	# Restore original resolv.conf<br /><br />	if [ -e $BACKUP ]; then<br />		mv $BACKUP $RESOLV<br />	fi<br />fi<br />

Now is a good time to make sure you’ve installed your VPN configuration into /etc/vpnc/default.conf. It’s a good idea to test out your vpnc config on another machine before running it on OpenWRT.

OK, let’s enable the services we need. You can do this from the OpenWRT web interface, or the command line:

/etc/init.d/ulogd enable
/etc/init.d/autostart-vpnc enable


Reboot your OpenWRT to get all the services set up. You’ll want to watch the system message log, so in one ssh connection run the log reader:

logread -f


and in another ssh connection start pinging a host in the VPN:

ping somehost.example.org


You should see a message in the system log, and after a short delay you’ll start getting ping responses. Make sure to test the auto-connect from a host plugged in to your OpenWRT’s LAN port as well as from the shell: if auto-connect works directly from the OpenWRT shell, but not from the LAN, then your iptables OUTPUT rule is correct but your FORWARD rule isn’t. (If the problem is reversed, then the rules are reversed.)

If auto-connection doesn’t work, you can check the log at /tmp/autoconnect-vpnc.log and then debug the process step-by-step:

1. First, check that your vpnc configuration works:
   vpnc
2. Then, check that the vpn_trigger iptables rule is being called by looking at the packet counts:
   iptables -L vpn_trigger -v
3. If vpn_trigger is being called, make sure that ulogd is writing to the correct file:
   cat /var/log/ulogd.syslogemu
4. check that the autoconnect script is actually running with ps

The hardest thing to check is that you have your DNS setup correct. I usually do this by checking the vpn_trigger rules first, then use nslookup to query a behind-the-vpn host.

using Scribefire to post to jim-st blog

the wysiwyg editor in the blogspot blog posting pags doesn't produce very good spacing or control over spacing and font sizes.  Hopefully a better html editor is provided in this tool.

https://addons.mozilla.org/en-US/firefox/addon/scribefire-blog-editor/

Courier is here.  example use will be to paste in a listing here in a blog and have it legible.

this is left default

xming windows x server

project for windows access X stuff

http://www.straightrunning.com/XmingNotes/

Bash redirection

http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO-3.html

3. All about redirection

3.1 Theory and quick reference

There are 3 file descriptors, stdin, stdout and stderr (std=standard).

Basically you can:

1. redirect stdout to a file
2. redirect stderr to a file
3. redirect stdout to a stderr
4. redirect stderr to a stdout
5. redirect stderr and stdout to a file
6. redirect stderr and stdout to stdout
7. redirect stderr and stdout to stderr

1 'represents' stdout and 2 stderr. A little note for seeing this things: with the less command you can view both stdout (which will remain on the buffer) and the stderr that will be printed on the screen, but erased as you try to 'browse' the buffer.

3.2 Sample: stdout 2 file

This will cause the ouput of a program to be written to a file.

        ls -l > ls-l.txt
        

Here, a file called 'ls-l.txt' will be created and it will contain what you would see on the screen if you type the command 'ls -l' and execute it.

3.3 Sample: stderr 2 file

This will cause the stderr ouput of a program to be written to a file.

        grep da * 2> grep-errors.txt
        

Here, a file called 'grep-errors.txt' will be created and it will contain what you would see the stderr portion of the output of the 'grep da *' command.

3.4 Sample: stdout 2 stderr

This will cause the stderr ouput of a program to be written to the same filedescriptor than stdout.

        grep da * 1>&2 
        

Here, the stdout portion of the command is sent to stderr, you may notice that in differen ways.

3.5 Sample: stderr 2 stdout

This will cause the stderr ouput of a program to be written to the same filedescriptor than stdout.

        grep * 2>&1
        

Here, the stderr portion of the command is sent to stdout, if you pipe to less, you'll see that lines that normally 'dissapear' (as they are written to stderr) are being kept now (because they're on stdout).

3.6 Sample: stderr and stdout 2 file

This will place every output of a program to a file. This is suitable sometimes for cron entries, if you want a command to pass in absolute silence.

        rm -f $(find / -name core) &> /dev/null 
        

This (thinking on the cron entry) will delete every file called 'core' in any directory. Notice that you should be pretty sure of what a command is doing if you are going to wipe it's output.