Make Ideas - Rocketry

Soda Bottle Rocket — DIY How-to from Make: Projects

Fix for re-imaging Lenovo X61t laptops

Problem:
Re-imaging using Clonezilla and rebooting a Lenovo X61t laptop threw up the error "Signature Failure"

Solution:
Quoting from http://www.ecs.umass.edu/pipermail/umasslug/2008-August/003380.html

However:  I did get the idea from various 
websites that it seemed to be an issue with the MBR, so I started 
playing with options in Clonezilla.  It turns out that if I de-select 
the -g auto and -r options, and select -t1, the system works.  I've just 
confirmed on two of the broken systems, so it looks like it's going to 
be a consistent fix.

  It looks like this is a common issue on the Lenovo laptops, so I'm 
glad to have found a solution.  (Also, I've got six more to image today, 
and possibly more next week...)

That worked.  It appears that -t1 replaces the MBR with the pre-made syslinux MBR.a

Registry Permissions resetting

Ok ... I could have used this recently as we migrated from an samba based domain to an AD domain.  The quickest way to migrate 20+ users was to just add the new domain user to the local admin group and then repoint their Docs and Settings folder to their old folder.

Using this subinacl tool (http://www.winhelponline.com/blog/reset-the-registry-and-the-file-permissions-in-windows-xp) might have made the process both easier and more secure.

Read up on Subinacl at http://www.microsoft.com/downloads/details.aspx?FamilyID=e8ba3e56-d8fe-4a91-93cf-ed6985e3927b&displaylang=en

Also check out SecEdit at http://support.microsoft.com/kb/313222/

IPCop SMTP Trap

After an event where a visitor managed to generate enough spam that our mail server was blacklisted, I decided to configure our firewall, IPCop, to prevent a future occurrence.

After a visit to the forums as well as the blog, http://www.subvs.co.uk/smtp_blocking_with_ipcop, I wrote a shell script to effect the desired blocks.

The Setup:

1. Guests are permitted only on the IPCop Blue network.
   
2. We have a local mail server 6xx.1.2.3 attached to our IPCop DMZ (Orange) network
3. Our primary domain MX server is reachable over the VPN at 192.168.y.y or over the internet at 5xx.1.2.3.  
4. Users on our trusted Green network are permitted to send mail to our MX server over the internet or over the VPN.
   
5. Our admin uses one local PC (192.168.x.x) for testing SMTP traffic so that IP is permitted to SMTP outbound anywhere.  

The Approach:

1. Permit any outbound SMTP from GREEN_IPOK1
2. Permit anyone on GREEN to connect to MX server (internet or VPN)
3. Permit local mail server to send outbound SMTP anywhere from ORANGE
4. Log and block all other outbound SMTP requests over the RED interface

The Limits:

1. Guests on the BLUE network can not send email via SMTP.  Period.
2. GREEN users can not send email except thru the MX server.

I chose to create a rc.firewall.smtp shell script file and then call it from within the rc.firewall.local script.  Made it easier to test without messing with the main firewall protections.

Caution:  Make sure that you run the rc.firewall.smtp stop before making any rule changes.  Eliminates a whole lot of cleanup later :)


The File:

#!/bin/sh
# Used to block outbound SMTP traffic
# Edited: AmAdmin 20090903

eval $(/usr/local/bin/readhash /var/ipcop/ppp/settings)
eval $(/usr/local/bin/readhash /var/ipcop/ethernet/settings)

# Local admin PC for SMTP testing
GREEN_OKIP1=192.168.x.x
# Local mail servers (VPN/MX/RELAY)
MAILSRV1=192.168.y.y
MAILSRV2=5xx.1.2.3
MAILSRV3=6xx.1.2.3

allow_smtp() {   
    # allow smtp outbound from networks to trusted mail server ips
    /sbin/iptables -$ACTION CUSTOMFORWARD -p tcp -i $GREEN_DEV -d $MAILSRV1 --dport 25 -j ACCEPT
    /sbin/iptables -$ACTION CUSTOMFORWARD -p tcp -i $GREEN_DEV -d $MAILSRV1 --dport 465 -j ACCEPT
    /sbin/iptables -$ACTION CUSTOMFORWARD -p tcp -i $GREEN_DEV -d $MAILSRV2 --dport 25 -j ACCEPT
    /sbin/iptables -$ACTION CUSTOMFORWARD -p tcp -i $GREEN_DEV -d $MAILSRV2 --dport 465 -j ACCEPT
    /sbin/iptables -$ACTION CUSTOMFORWARD -p tcp -i $ORANGE_DEV -s $MAILSRV3 --dport 25 -j ACCEPT
    /sbin/iptables -$ACTION CUSTOMFORWARD -p tcp -i $ORANGE_DEV -s $MAILSRV3 --dport 465 -j ACCEPT
    # permit smtp outbound from trusted GREEN ip addresses to anywhere
    /sbin/iptables -$ACTION CUSTOMFORWARD -p tcp -i $GREEN_DEV -s $GREEN_OKIP1 --dport 25 -j ACCEPT
    /sbin/iptables -$ACTION CUSTOMFORWARD -p tcp -i $GREEN_DEV -s $GREEN_OKIP1 --dport 465 -j ACCEPT
}

log_smtp() {
    # log all stmtp outbound from RED
    /sbin/iptables -$ACTION CUSTOMFORWARD -p tcp -o $RED_DEV --dport 25 -j LOG --log-prefix "SMTP_"
    /sbin/iptables -$ACTION CUSTOMFORWARD -p tcp -o $RED_DEV --dport 465 -j LOG --log-prefix "SMTP-SSL_"
}
   
block_smtp() {
    # block all stmtp outbound from RED
    /sbin/iptables -$ACTION CUSTOMFORWARD -p tcp -o $RED_DEV --dport 25 -j DROP
    /sbin/iptables -$ACTION CUSTOMFORWARD -p tcp -o $RED_DEV --dport 465 -j DROP
}

# See how we were called.
case "$1" in
  start)
        ## add your 'start' rules here
        ACTION=A
        allow_smtp
        log_smtp
        block_smtp
       ;;
  stop)
        ## add your 'stop' rules here
        ACTION=D
        allow_smtp
        log_smtp
        block_smtp
        ;;
  reload)
        $0 stop
        $0 start
        ## add your 'reload' rules here
        ;;
  status)
        /sbin/iptables -nvL CUSTOMFORWARD
        ;;
  *)
        echo "Usage: $0 {start|stop|reload|status}"
        ;;
esac

Copy path to clipboard - XP64

This is a utility that I immensely enjoyed once I found it. I didn't
know how _much_ I used it until I moved to XP64 and 'lost' that
functionality. What a pain!

However, I finally found a replacement that "just works";
http://stefan.bertels.org/en/clipboardpath

I just installed V1.2 and it worked without even requiring a reboot!
One nice feature is the use of the CTRL key to translate the path to
the full UNC path. That could be very useful as the UNC is common
across all users but the share mapping may be different.

<clapping hands>

Sent from my Verizon Wireless BlackBerry

HELP! My Blackberry 8330 won't activate with my BES!

Situation:

I have a BES 4.1 running on Lotus Domino 6.5 on Windows Server 2003 SP2. I replaced my Curve 8330 because the battery cover spring latch broke. Verizon replaced the phone requiring me to reassign the new device to my user account on the BES.

Simple, right? Been there ... done that. Except that email activation didn't work.

LO-O-ONG story made short ... the email antispam firewall (did I mention that ASSP v1.3.3.8 has been _awesome_ in reducing our spam traffic?) tagged the activation email from blackberry.net as spam. The BES never received the activation request so it could not validate the request and the phone never completed the activation process.

Strangely enough, although I could attach the new phone to the BES via USB cable and even see the newly attached device in the manager, I could not view the properties of the phone, assign it to a user account, nor even 'nuke' the phone (that _may_ have been a really good thing :). Evidently those menu choices don't work until the device is activated by the BES.

Verizon tech support attempted to assist even though they don't usually assist with BES issues. The did have me go to Options .... Advanced ... Host Routing Tables and open the menu and click on ACTIVATE. After that process, I did get access to the internet (was not available before) and my signal went from 1X to 1XEV. Not sure if related or not ...

Solution:

Add na.blackberry.net to the ASSP configuration as a whitelisted domain.

Set environment variables

Setx - Set environment variables

Although this command, SETX, does not appear to work in XP SP2, there is a tidbit of useful info near the page end.

To add a machine variable to the environment, run the following as an admin from the command line:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /v /d "some data"