Tuesday, November 24, 2009

Eee PC (Ubuntu)

The Eee PC is quite a effective, and small unit. It's lasted three months in my hands, which is probably a good sign (realizing how I've screwed up the keyboard with soapy-wet hands)

Ubuntu Netbook remix made a big leap in the latest release, also.
Maximus seems more stable, and the layout is quite a bit better.



The main problem is when you switch to Ubuntu there are certain features, like disabling:
- Camera
- Card Reader
- Wireless
That you can't fully control. Sure you can disable the "wireless" in Ubuntu, but the actual wireless card is still on unless you disable it in bios.

eee-control fixes this though.
The version in Jaunty is quite effective. It controls wireless, camera, card reader, brightness, processor and fan speeds, and probably some other things I forgot.

If you like the newest version of Ubuntu (9.10), then you're out of luck. Building eee-control fails.
Rumor has it that the karmic build will be available soon.

Wednesday, November 18, 2009

Mutt: Scripting mail

With 'mutt' we can generate e-mails and have them sent to our default e-mail address, in this case me@domain.com
mutt -s "Subject line here" me@domain.com < /path/to/message
is the correct command for this e-mail address. You can find more details at http://www.cyberciti.biz/tips/sending-mail-with-attachment.html or the man page of mutt.

In the end, my script looks like this:
# Sends the IP address to default address
to="me"
from="noreply"
domain="domain.com"
temp=`mktemp -t`
ifconfig ppp0 > $temp
mutt -e "set from=$from@$domain" -s "IP address - $HOSTNAME" "$to@$domain" < $temp

$HOSTNAME is set based off the hostname of the computer. In my case this name is specific to the location and is unique. This helps me know which school I'm contacting.
The other main addition is the "-e" command.
If you look online you'll find that in order to send from a specific domain, you need to set up a muttrc file. Since we're running a script, and it makes more sense to keep everything together, I decided it's better to just add the "set from=" command in the script instead of an outside file.
The "-e" command lets you do this. It must be in quotes, otherwise it'll throw an error.

This is also added to the ip-up script that is run when ppp0 makes a connection.

You'll then need to make sure that postfix is installed. The best way, is to set up postfix and have it send through a designated email address. I simply set up a "noreply" email address on our domain that I would log into to send the email.
You can find instructions here: http://serverfault.com/questions/119278/configure-postfix-to-send-relay-emails-gmail-smtp-gmail-com-via-port-587/119296#119296

Squid -- Transparency

Edit: updated for what I'm currently doing in 10.04 and 10.10 (ubuntu)

A few guides gave ideas on how to get iptables to work:
# Add to IP tables
# squid server IP
lan=`ifconfig -s | grep eth | awk '{print $1}'`
s_port="3128"
iptables -t nat -A PREROUTING -i $lan -p tcp --dport 80 -j REDIRECT --to-port $s_port


The problem is on restarting the computer, it seemed to disappear. So I thought I had figured it out, until it didn't work anymore.

Eventually I ended up re-building it each time ppp0 was created by putting it as a process in ip-up.d/

Oh, also don't forget to add "transparent" to the line in the squid.conf file.

http_port 3128 transparent
To learn more about iptables: http://www.frozentux.net/documents/iptables-tutorial/

From here you can directly connect squid to apt-cacher-ng, and have transparent caching of your debian files. Just set up apt-cacher-ng as a peer.

Squid

Squid was relatively easy to set up. There were a few pitfalls, as there are with most programs that seem rather critical to internet usage.

For the most part there was very little deviation from from the regular config, so instead of listing my whole configuration, I'm going to simply list the options I chose and why.

Note: this was written using Squid3

ACL list
In order to define who has access and who doesn't, you probably have noticed that squid.conf has an acl list. In version 3, the acl section is around line 400. It's important to edit this so that the squid server allows connections from your localnet and your localhost.
example:
acl localhost src 127.0.0.1/32
acl localnet src 10.42.43.0/255.255.255.0
I saw many ways to configure the localnet ip address, some being relatively simple (10.42.43.0/32) but this way seems the most obvious, and a bit less confusing.
It's of course important to then set:
http_access allow localnet
http_access allow localhost

http_port
By default the port is set to 3128. But you already knew that. If for some reason you know how to set up a transparent proxy, you can type "transparent" after the port you want to transparently listen. Transparency is a post in and of itself.
What you should realize is that "accel" doesn't refer to accelerating the connection in any way. Unless you know what this means (which I still haven't figured out) you probably shouldn't use it.

Replacement Policies (the cache)
There are two places the cache is stored in: memory and hard disk. For the most part the cache can be left alone, but it makes sense to at least mess around with how the cache works.
The Replacement policy that I used were:
heap GDSF : for the memory
heap LFUDA : for the disk cache
From the config file:

The heap GDSF policy optimizes object hit rate by keeping smaller popular objects in cache so it has a better chance of getting a hit. It achieves a lower byte hit rate than LFUDA though since it evicts larger (possibly popular) objects.

The heap LFUDA policy keeps popular objects in cache regardless of their size and thus optimizes byte hit rate at the expense of hit rate since one large, popular object will prevent many smaller, slightly less popular objects from being cached.

So while LFUDA is most important (saving bandwidth) for our purposes, GDSF might as well be used for memory to increase memory hits.


Paths to know:
/var/spool/squid - where the cache is stored
/var/log/squid - where to access the logs:
access.log should ping whenever someone connects. it's nice to see how effective the server is
cache.log is often used for logging
/etc/squid - where the logs are stored
/etc/init.d/squid - to restart the server

These paths MAY OR MAY NOT have a 3 after them, depending on your version.

Some of the resources I found helpful are:
Squid - The Definite Guide : http://oreilly.com/catalog/9780596001629
Squid by Oskar Pearson : http://proxy.ccu.edu.tw/squid/index.html

Hand in hand with Squid is SquidGuard.