Grace (PDF)

cache_ef­fec­tive_user proxy
cache_ef­fec­tive_group proxy

http_port 3128
http_ac­cess al­low all

acl lo­cal_ips dst 127.0.0.0/8 192.168.0.0/24 10.10.0.0/16
acl lo­cal_servers dst­do­main lo­cal­host my.lo­cal.do­main
nev­er_di­rect al­low all
al­ways_di­rect al­low lo­cal_ips
al­ways_di­rect al­low lo­cal_servers

acl http-on­ly port 80
cache_peer first­Proxy.site.com par­ent 3128 3190 no-query proxy-on­ly login=User­name:Pass­word name=prx1
cache_peer sec­ond­Proxy.site.com par­ent 3128 3190 no-query proxy-on­ly login=User­name:Pass­word de­fault name=prx2

# This makes on­ly HTTP load bal­anced
cache_peer_ac­cess prx1 deny all
cache_peer_ac­cess prx1 al­low http-on­ly
cache_peer_ac­cess prx2 al­low all

# Re­in­force­ment of di­rect rules
cache_peer_ac­cess prx1 deny lo­cal_ips
cache_peer_ac­cess prx1 deny lo­cal_servers
cache_peer_ac­cess prx2 deny lo­cal_ips
cache_peer_ac­cess prx2 deny lo­cal_servers

# Some time­outs
con­nect_time­out 8 sec­onds
peer_con­nect_time­out 3 sec­onds

hier­ar­chy_sto­plist cgi-bin ?

cache_mem 64 MB
max­i­mum_ob­ject_size_in_mem­o­ry 64 KB

cache_re­place­ment_pol­i­cy heap GDSF
cache_dir aufs /var/spool/squid3 6000 16 256  # Make sure to check this path
max­i­mum_ob­ject_size 16384 KB

ac­cess_log /var/log/squid3/ac­cess.log squid  # Make sure to check this path

shut­down_life­time 3 sec­onds

de­bug_op­tions ALL,1

My disk ac­cess prob­lems prob­a­bly stem from the fact that my VMware disk and my sys­tem boot disk are both the same par­ti­tion and the same disk. This prob­a­bly caus­es all sorts of ac­cess is­sues, espe­cial­ly while my com­put­er is boot­ing (I have no­ticed that my com­put­er takes forever to stop thrash­ing the disk after log­ging in). The net­work prob­lems are more eva­sive, how­ev­er. I’m us­ing the NAT net­work­ing in­ter­face so that I can as­sign my Ubun­tu a stat­ic IP ad­dress that will nev­er change, even if my phys­i­cal com­put­er changes lo­ca­tion (and it will, often). How­ev­er, pret­ty fre­quent­ly the DNS “server” that VMware pro­vides breaks down, and while Ubun­tu is able to send pack­ets to the net­work, it can­not per­form DNS queries through the lo­cal DNS ser­vice. Oc­ca­sion­al­ly, the net­work will fail to op­er­ate al­to­geth­er, and Ubun­tu will be un­able to send any pack­ets any­where (in­clud­ing to the host com­put­er!). This is a prob­lem which I’ve looked for so­lu­tions for on­line, but have so far come up with noth­ing.

Fi­nal­ly, I would like to be able to serve files from the host com­put­er through a web server on Ubun­tu, and my cur­rent method of mount­ing the host shares with CIFS and then shar­ing them with Apache is not op­ti­mal (the least of the prob­lems with this method is re­dun­dant net­work usage). I would like to get the VMware shared fold­ers fea­ture work­ing, ex­cept that I can­not seem to com­pile the VMware tools’ ker­nel mod­ules on Ubun­tu 8.04 (even fol­low­ing other ref­er­ences on­line). VMware’s ker­nel mod­ule builder is not quite as pol­ished, ev­i­dent­ly, as others’ (like nVidia).

Hope­ful­ly I will find so­lu­tions to the­se prob­lems soon, as I re­al­ly like the idea of run­ning a vir­tu­al­ized Lin­ux server on a Win­dows host, and hope that this sort of ar­range­ment will prove fruit­ful.

Here’s a lit­tle pro­gram I wrote to solve a small prob­lem I’ve been hav­ing with cron. Say one has in one’s crontab the fol­low­ing line:

0 0 * * * /usr/bin/rsync -avz dir1/ /back­up/dir1/

This backs up dir1 to a back­up di­rec­to­ry. rsync, how­ev­er, cre­ates a lot of out­put (espe­cial­ly with the -v switch)… and cron sends that out­put to your email, so ev­ery day, you’ll be get­ting an email mes­sage from cron with the re­sults of the back­up. To avoid this, most peo­ple sim­ply redi­rect the out­put to /dev/null. What if I do ac­tu­al­ly want to see the out­put though, just not in my in­box? crar­chive is a lit­tle script that will log the re­sults of cron runs in a fold­er, gzip old logs, and delete re­al­ly old logs au­to­mat­i­cal­ly. It al­lows the out­put of com­mands run in cron to be saved and archived, but with­out clog­ging up your in­box. Even­tu­al­ly, it will al­so sup­port more cus­tomiz­abil­i­ty, but be­cause this is on­ly the first re­lease, it has the fol­low­ing lim­i­ta­tions…

• Max­i­mum one run per day
• Logs to $HOME/logs (un­change­able)
• Gzips logs that are one day old, deletes logs that are thir­ty (un­change­able)

crar­chive will, how­ev­er, email you if some­thing goes wrong (un­for­tu­nate­ly, again, er­ror check­ing in this ear­ly ver­sion is prim­i­tive). Here’s a usage ex­am­ple with the crontab from ear­lier (as­sum­ing we’ve in­stalled crar­chive.py in­to /usr/bin):

0 0 * * * /usr/bin/rsync -avz dir1/ /back­up/dir1/ | /usr/bin/crar­chive.py rsync-dir1

Where rsync-dir1 is an ar­bi­trary name that you choose.

I’m cur­rent­ly us­ing crar­chive to log an aw­stats up­date that I’m run­ning in my crontab. If you think that crar­chive would be of some use to you, down­load ver­sion 0.1.