Wednesday, April 15, 2009
A Gun for the Time Hole
An ordinary AK-47 Kalashnikov automatic rifle would not be allowed through the time hole. One made of bacon, however, is an ideal candidate for the time-traveling freedom fighter.
Monday, March 23, 2009
Sunday, March 15, 2009
Handling HTTP Redirection in Ruby
I have a Ruby project where I'm dumping a bunch of bookmarks from delicious.com, then fetching each bookmarked page for analysis.
One of the problems I encountered early on is that the some of the web pages bookmarked would redirect to some other location. Simply checking for HTTP response code 200 was insufficient. I needed to check for redirection as well.
A quick Google search for "ruby follow http redirect" yields lots of results. Unfortunately, they're all very similar, and not quite right. In general, the examples you come across (even the one in the official Ruby documentation) don't handle the case when the redirected location is path relative to the original location. So you end up doing a get on a URL that looks like "../../redirected/location/index.html," which clearly won't work.
It turns out that detecting relative redirection is fairly straightforward:
The trick here is to ask the redirected url object if it is relative. If it is, then add the redirected path onto the old url object. the URI class overrides the '+' operator (what is this, C++?) so that you can concatenate the new path onto the old URL, by doing:
newurl=url+resp.header['location']
One of the problems I encountered early on is that the some of the web pages bookmarked would redirect to some other location. Simply checking for HTTP response code 200 was insufficient. I needed to check for redirection as well.
A quick Google search for "ruby follow http redirect" yields lots of results. Unfortunately, they're all very similar, and not quite right. In general, the examples you come across (even the one in the official Ruby documentation) don't handle the case when the redirected location is path relative to the original location. So you end up doing a get on a URL that looks like "../../redirected/location/index.html," which clearly won't work.
It turns out that detecting relative redirection is fairly straightforward:
until( found || attempts>=@@MAX_ATTEMPTS)
attempts+=1
http=Net::HTTP.new(url.host,url.port)
http.open_timeout = 10
http.read_timeout = 10
path=url.path
path="/" if path==""
req=Net::HTTP::Get.new(path,{'User-Agent'=>@@AGENT})
if url.instance_of? URI::HTTPS
http.use_ssl=true
http.verify_mode = OpenSSL::SSL::VERIFY_NONE
end
resp=http.request(req)
if resp.code=="200"
break
end
if (resp.header['location']!=nil)
newurl=URI.parse(resp.header['location'])
if(newurl.relative?)
puts "url was relative"
newurl=url+resp.header['location']
end
url=newurl
else
found=true #resp was 404, etc
end #end if location
end #until
The trick here is to ask the redirected url object if it is relative. If it is, then add the redirected path onto the old url object. the URI class overrides the '+' operator (what is this, C++?) so that you can concatenate the new path onto the old URL, by doing:
newurl=url+resp.header['location']
Thursday, March 12, 2009
Mounting LVM Disks in Ubuntu
I always thought LVM (Linux's Logical Volume Manager) was kind of neat for the flexibility it gives you in adding and removing disks and resizing volumes such. However, in practice, I find it's usually more trouble than it's worth. It adds a layer of complexity between me and my data.
Often I need to mount a disk configured with LVM on another Linux machine or in an Ubuntu live CD environment. Out of the box the logical volumes aren't recognized, so I can't mount them.
It's fairly easy to add LVM support and mount the volumes though.
You install the lvm2 package, load the device mapper kernel module, and then activate any lvm volume groups on your disk.
$ sudo apt-get install lvm2
$ sudo modprobe dm-mod
$ sudo vgchange -a y
(assuming your disk with logical volumes is already connected)
$ sudo mount /dev/mapper/<logical volume name> /mnt
And that's all there is to it.
If you want to deactivate the volume groups (recommended before unplugging a USB disk with logical volumes):
$ sudo vgchange -a n
Warning: the above command will deactivate all volume groups, so check the vgchange manpage first, if that's not what you want.
Often I need to mount a disk configured with LVM on another Linux machine or in an Ubuntu live CD environment. Out of the box the logical volumes aren't recognized, so I can't mount them.
It's fairly easy to add LVM support and mount the volumes though.
You install the lvm2 package, load the device mapper kernel module, and then activate any lvm volume groups on your disk.
$ sudo apt-get install lvm2
$ sudo modprobe dm-mod
$ sudo vgchange -a y
(assuming your disk with logical volumes is already connected)
$ sudo mount /dev/mapper/<logical volume name> /mnt
And that's all there is to it.
If you want to deactivate the volume groups (recommended before unplugging a USB disk with logical volumes):
$ sudo vgchange -a n
Warning: the above command will deactivate all volume groups, so check the vgchange manpage first, if that's not what you want.
Monday, March 09, 2009
The Rules of the Time Hole
There was a great video on College Humor addressing why terminators travel back in time naked.
That said, I think it's worth discussing the rules of time travel or "the time hole" as my colleague Ross and I put it. So if you've followed the Terminator movies, and, more recently, Terminator: The Sarah Connor Chronicles, the rules of the time hole are fairly easy to infer.
Things can go through the time hole if:
In Terminator 2, we see the T-1000, which is constructed of a "mimetic poly-alloy," i.e., liquid metal, travel through time. Clearly, the T-1000 qualifies under rule #3 as it looks, very convincingly, like it is made of meat. Similarly, in Terminator 3, we see the T-X come back in time. The T-X is much like the T-1000, except hot.
Later, in the The Sarah Connor Chronicles, we see Cameron (a terminator wrapped in meat), John, and Sarah (both made of meat) travel back in time. However, just before the time hole closes, Cromartie's severed head (devoid of its meat wrapping) flies through after them.
I checked all terminator-related facts presented above on wikipedia.org.
That said, I think it's worth discussing the rules of time travel or "the time hole" as my colleague Ross and I put it. So if you've followed the Terminator movies, and, more recently, Terminator: The Sarah Connor Chronicles, the rules of the time hole are fairly easy to infer.
Things can go through the time hole if:
- They are made of meat
- They are wrappped in meat
- They look very much like they are made of meat
- If several things meeting the above rules go through all at once, something else may sneak through behind them.
In Terminator 2, we see the T-1000, which is constructed of a "mimetic poly-alloy," i.e., liquid metal, travel through time. Clearly, the T-1000 qualifies under rule #3 as it looks, very convincingly, like it is made of meat. Similarly, in Terminator 3, we see the T-X come back in time. The T-X is much like the T-1000, except hot.
Later, in the The Sarah Connor Chronicles, we see Cameron (a terminator wrapped in meat), John, and Sarah (both made of meat) travel back in time. However, just before the time hole closes, Cromartie's severed head (devoid of its meat wrapping) flies through after them.
I checked all terminator-related facts presented above on wikipedia.org.
Saturday, January 10, 2009
OS X: How to detect whether you're on battery from the shell
Sometimes you need to determine programatically whether a computer is on battery or on AC. For example, I have a backup script that takes hourly snapshots of my home directory on my MacBook Pro (which I hopefully will post about at some point). However, I don't want the script to run if I'm on battery. Ideally, launchd, which kicks off the script, could give me this option, but I don't think it can. I'll have to let the script make the decision when it gets executed.
If I were writing the script for Linux, I'd have it look through /proc/acpi/ to check the state of the battery. There's no /proc in OS X. There is, however, a power management command, pmset.
If I run pmset -g while on AC, I get:
If I run it while on battery, I get:
I simply have my script grep the output from pmset for "discharging":
See the pmset(1) manpage for more info.
If I were writing the script for Linux, I'd have it look through /proc/acpi/ to check the state of the battery. There's no /proc in OS X. There is, however, a power management command, pmset.
If I run pmset -g while on AC, I get:
Currently drawing from 'AC Power'
-InternalBattery-0 100%; AC attached; not charging
If I run it while on battery, I get:
Currently drawing from 'Battery Power'
-InternalBattery-0 100%; discharging; (no estimate)
I simply have my script grep the output from pmset for "discharging":
checkBattery()
{
local ret=0;
if $PMSET -g batt | $GREP -q discharging;
then
ret=1;
fi
return $ret;
}
See the pmset(1) manpage for more info.
Friday, January 09, 2009
Converting a .dmg to a .iso
I have an operating system install image that I need to install in VMware Fusion. The problem is the install image is a MacOS disk image file, or .dmg. I need a DVD image, or a .iso, in order to boot the VM and do the install.
It turns out that the Mac OS X command hdiutil to convert the .dmg to a .iso:
See the hdiutil(1) manpage for more info.
It turns out that the Mac OS X command hdiutil to convert the .dmg to a .iso:
hdiutil convert.dmg -format UDTO -o .iso
See the hdiutil(1) manpage for more info.
Thursday, January 08, 2009
How to sudoedit non-interactively
Okay, this one's a bit esoteric, but I think it's pretty cool. How do you use 'sudoedit' non-interactively such as from a script? Just a brief background about sudo: sudo is an authentication mechanism in Unix & Linux that allows unprivileged users to run specific commands (as defined by the system administrator) with root privileges without having the root password. This has several advantages over logging in as root:
So, what if you want to make changes to a system file via a script, and the only access you have to the file is via sudoedit? It isn't useful to have the script call sudoedit and then bring up vi for you to manually make the changes.
Well, the way sudoedit works, is that sudo makes a temporary copy of the file you want to edit, then calls your default editor, giving it the name of the temp file as the first argument. So, say your default editor is "fooedit". You run "sudoedit /etc/systemfile" and sudo makes a copy of /etc/systemfile to /tmp then runs "fooedit /tmp/tempfile". Your changes are saved to the temp file. When your editor exits, sudo copies the temp file over the original, and then removes the temp file.
From your main script, stage the pre-edited version of the system file, then set your default editor to a custom script that will copy that staged file over the temp file. When it exits, sudo will copy the temp file into place as normal.
Your script would go like this:
Your custom script would look like:
This script just cats your pre-staged file over whatever sudo passed in as the first argument ($1).
The only interaction you'll have to do is type your password for sudo, if you haven't already done so in the last few minutes (sudo temporarily remembers your authentication).
- Users can have specific, limited set of root privileges without having the entire set of root privileges.
- Users use their own password, so the root password doesn't have to be shared. If a user's sudo privileges are revoked, the root password doesn't have to be reset.
- Each use of sudo is audited per user, so that each time sudo privileges are invoked, there is an event in the system logs that identifies the specific user and the command they ran.
So, what if you want to make changes to a system file via a script, and the only access you have to the file is via sudoedit? It isn't useful to have the script call sudoedit and then bring up vi for you to manually make the changes.
Well, the way sudoedit works, is that sudo makes a temporary copy of the file you want to edit, then calls your default editor, giving it the name of the temp file as the first argument. So, say your default editor is "fooedit". You run "sudoedit /etc/systemfile" and sudo makes a copy of /etc/systemfile to /tmp then runs "fooedit /tmp/tempfile". Your changes are saved to the temp file. When your editor exits, sudo copies the temp file over the original, and then removes the temp file.
From your main script, stage the pre-edited version of the system file, then set your default editor to a custom script that will copy that staged file over the temp file. When it exits, sudo will copy the temp file into place as normal.
Your script would go like this:
#!/bin/sh
export EDITOR="/bin/sh ./editor.sh";
PRE_STAGE=/tmp/stage.tmp;
echo "my new config"> $PRE_STAGE;
sudoedit /etc/config;
/bin/rm $PRE_STAGE;
exit;
Your custom script would look like:
#!/bin/sh
CAT=/bin/cat
PRE_STAGE="/tmp/stage.tmp"
$CAT $PRE_STAGE > "$1";
exit;
This script just cats your pre-staged file over whatever sudo passed in as the first argument ($1).
The only interaction you'll have to do is type your password for sudo, if you haven't already done so in the last few minutes (sudo temporarily remembers your authentication).
Sunday, December 21, 2008
MythTV, HD-PVR, Trunk
Until Hauppauge released the HD-PVR this past May, there was no way to record in high-definition from your cable or satellite box. Your HD recording options were limited to over-the-air, unencrypted QAM, or, in rare instances, unencrypted firewire from the cable box. In any case there was no way to record the good stuff in HD. I'll spare the details about the HD-PVR itself, and instead include some links at the end.
Of course, Linux support for the HD-PVR wasn't available straight away. However, this is a big breakthrough for homebrew PVRs so the MythTV/Linux community has been hard at work. It there is a Linux driver for the HD-PVR, but you have to check it out and build it yourself (See links at the end). Also, early work has been done on MythTV to support the HD-PVR, but in order to get that support, you have to run MythTV from trunk, rather than using your distribution's packaged version. This means checking out source and building it yourself. The source code changes daily, and at times things get worse before they get better. Whatever you check out on any given day should be in decent shape, but it may not be. You are forging MythTV from the molten center of the Earth, and it's still hot and a little bit on fire.
What is now in trunk will eventually make it into your distribution, but there's generally a 6-12 month lag, depending on your distribution's release cycle. Well, I'm ready to give the HD-PVR a try now, so I decided to give trunk a go. I set up a spare machine on my work bench to be a frontend and backend. After getting the HD-PVR drivers compiled and working, I checked out MythTV from subversion and built it. There are good documents detailing how to do this. It's actually not that hard. The build system for MythTV is very nice. I recommend starting with a MythTV based distribution like Mythbuntu, and removing all the mythtv packages. This will save you a lot of grunt work like setting up MySQL, the mythtv user, init script, etc.
Anyway, I've got the HD-PVR working with MythTV. I haven't used it for any actual TV watching or recording yet. As soon as I can get a frontend set up, I'll be able to actually try using it day-to-day.
Relevant links:
http://www.geektonic.com/2008/06/hauppauge-hd-pvr-unboxing-first-look.html
http://mythtvnews.com/2008/05/30/hauppauge-hd-pvr-support-coming-for-mythtv-devices-are-shipping-now/
http://mythtvnews.com/2008/06/14/hauppauge-hd-pvr-linux-driver-released-alpha-quality/
http://www.mythtv.org/wiki/index.php/Ubuntu_Installation_Guides
http://www.mythtv.org/wiki/index.php/Hauppauge_HD-PVR
Of course, Linux support for the HD-PVR wasn't available straight away. However, this is a big breakthrough for homebrew PVRs so the MythTV/Linux community has been hard at work. It there is a Linux driver for the HD-PVR, but you have to check it out and build it yourself (See links at the end). Also, early work has been done on MythTV to support the HD-PVR, but in order to get that support, you have to run MythTV from trunk, rather than using your distribution's packaged version. This means checking out source and building it yourself. The source code changes daily, and at times things get worse before they get better. Whatever you check out on any given day should be in decent shape, but it may not be. You are forging MythTV from the molten center of the Earth, and it's still hot and a little bit on fire.
What is now in trunk will eventually make it into your distribution, but there's generally a 6-12 month lag, depending on your distribution's release cycle. Well, I'm ready to give the HD-PVR a try now, so I decided to give trunk a go. I set up a spare machine on my work bench to be a frontend and backend. After getting the HD-PVR drivers compiled and working, I checked out MythTV from subversion and built it. There are good documents detailing how to do this. It's actually not that hard. The build system for MythTV is very nice. I recommend starting with a MythTV based distribution like Mythbuntu, and removing all the mythtv packages. This will save you a lot of grunt work like setting up MySQL, the mythtv user, init script, etc.
Anyway, I've got the HD-PVR working with MythTV. I haven't used it for any actual TV watching or recording yet. As soon as I can get a frontend set up, I'll be able to actually try using it day-to-day.
Relevant links:
http://www.geektonic.com/2008/06/hauppauge-hd-pvr-unboxing-first-look.html
http://mythtvnews.com/2008/05/30/hauppauge-hd-pvr-support-coming-for-mythtv-devices-are-shipping-now/
http://mythtvnews.com/2008/06/14/hauppauge-hd-pvr-linux-driver-released-alpha-quality/
http://www.mythtv.org/wiki/index.php/Ubuntu_Installation_Guides
http://www.mythtv.org/wiki/index.php/Hauppauge_HD-PVR
Ditching apt-cacher-ng for Squid
apt-cacher-ng hasn't exactly worked out as well as I had hoped. I kept having a problem where the Releases file from the apt repository would be reported as corrupted. I could go into the cache directory and manually remove that file, forcing it to be downloaded again, but that would only help with the system I was updating at the moment. The next system that I tried to update would have the same problem.
I've read a number of articles about just using Squid as an apt cache. I avoided this at first because Squid isn't really made for that. For example squid has no way of knowing when a specific version of a package has been made obsolete by a newer version. I assume apt-cacher-ng and apt-proxy know how to do this (maybe not). Also Squid isn't intended to cache arbitrarily sized objects for indefinite periods of time. I decided to give it a try though, since a number of people seem to be having success with this.
I had to tweak Squid's default configuration a bit to make it suitable for apt-caching.
The Squid configuration file is well documented, but below are the directives of interest:
refresh_pattern deb$ 1577846 100% 1577846
refresh_pattern Packages.gz$ 1440 100% 1440
cache_dir ufs /var/spool/squid 15000 2 8
maximum_object_size 409600 KB
The first line says to cache anything ending ('$' is the end-of-line anchor) in "deb" for 3 years. There are some packages that rarely get updated if ever, so I want to make they stay in the cache the entire time I'm using a given distribution release. I figure I'll probably be on a particular distribution release for no longer than three years.
The second line says to cache anything ending in "Packages.gz" for one day.
The "cache_dir" line says to put Squid's cache in /var/spool/squid (I believe this is the default). It also says to let it grow no larger than 15,000 megabytes. My system partition gets very little use, so 15Gb is no problem for me. The second two numbers tell Squid how to structure the cache. "2" says to create two level 1 directories and "8" says to create 8 level 2 directories. The default is 16 and 256. I read an article where the author was having a problem with the hard drive never spinning down because Squid was rescanning the cache every few seconds. The author said reducing the number of L1 and L2 directories helped. If anyone can find this article, please post a link in the comments.
The "maximum_object_size" tells squid to cache objects up to 400Mb. There shouldn't be any debs even close to that large. Squid's default is much smaller than this.
In order to get apt to use the proxy, I created a file called "proxy" in /etc/apt/apt.conf.d/. You can call the file whatever you want. The file contains the line:
Acquire::http::Proxy "http://hoth:3128";
"hoth" is the hostname of the Squid server. Make sure there are no "Acquire" directives in any other apt configuration file:
/etc/apt/ # grep -rn Acquire *
I discovered that on some systems there was an "Acquire" directive explicitly telling apt not to use a proxy.
So far, Squid has been working pretty well. There was one instance where apt failed to completely download a package, but after running apt-get dist-upgrade again, the package successfully downloaded.
I've read a number of articles about just using Squid as an apt cache. I avoided this at first because Squid isn't really made for that. For example squid has no way of knowing when a specific version of a package has been made obsolete by a newer version. I assume apt-cacher-ng and apt-proxy know how to do this (maybe not). Also Squid isn't intended to cache arbitrarily sized objects for indefinite periods of time. I decided to give it a try though, since a number of people seem to be having success with this.
I had to tweak Squid's default configuration a bit to make it suitable for apt-caching.
The Squid configuration file is well documented, but below are the directives of interest:
refresh_pattern deb$ 1577846 100% 1577846
refresh_pattern Packages.gz$ 1440 100% 1440
cache_dir ufs /var/spool/squid 15000 2 8
maximum_object_size 409600 KB
The first line says to cache anything ending ('$' is the end-of-line anchor) in "deb" for 3 years. There are some packages that rarely get updated if ever, so I want to make they stay in the cache the entire time I'm using a given distribution release. I figure I'll probably be on a particular distribution release for no longer than three years.
The second line says to cache anything ending in "Packages.gz" for one day.
The "cache_dir" line says to put Squid's cache in /var/spool/squid (I believe this is the default). It also says to let it grow no larger than 15,000 megabytes. My system partition gets very little use, so 15Gb is no problem for me. The second two numbers tell Squid how to structure the cache. "2" says to create two level 1 directories and "8" says to create 8 level 2 directories. The default is 16 and 256. I read an article where the author was having a problem with the hard drive never spinning down because Squid was rescanning the cache every few seconds. The author said reducing the number of L1 and L2 directories helped. If anyone can find this article, please post a link in the comments.
The "maximum_object_size" tells squid to cache objects up to 400Mb. There shouldn't be any debs even close to that large. Squid's default is much smaller than this.
In order to get apt to use the proxy, I created a file called "proxy" in /etc/apt/apt.conf.d/. You can call the file whatever you want. The file contains the line:
Acquire::http::Proxy "http://hoth:3128";
"hoth" is the hostname of the Squid server. Make sure there are no "Acquire" directives in any other apt configuration file:
/etc/apt/ # grep -rn Acquire *
I discovered that on some systems there was an "Acquire" directive explicitly telling apt not to use a proxy.
So far, Squid has been working pretty well. There was one instance where apt failed to completely download a package, but after running apt-get dist-upgrade again, the package successfully downloaded.
Tuesday, October 07, 2008
FiOS
We just got our FiOS internet hooked up. I opted for the 20Mbs up, 5Mbs down option. Here's a bandwith test from speedtest.net:
Other than being really annoyed at how difficult (i.e. almost impossible) Verizon makes it to use your own router instead of theirs, it's pretty awesome. I'm in the process of wget-ting the internet as we speak. Starting with .com.
Other than being really annoyed at how difficult (i.e. almost impossible) Verizon makes it to use your own router instead of theirs, it's pretty awesome. I'm in the process of wget-ting the internet as we speak. Starting with .com.
Wednesday, October 01, 2008
Awesome Log Message
I saw the greatest log message in my MacBook's system log this morning.
SyncServer[8551]: SyncServer: Truth vacuumed. Next vacuum date 2008-10-15 08:13:17 -0400
I'm sure it's something normal, and, given appropriate context, would make perfect sense. But I am just amused that the SyncServer is vacuuming up all the truth. No wonder I have a hard time finding useful log messages when I'm trying to troubleshoot something.
SyncServer[8551]: SyncServer: Truth vacuumed. Next vacuum date 2008-10-15 08:13:17 -0400
I'm sure it's something normal, and, given appropriate context, would make perfect sense. But I am just amused that the SyncServer is vacuuming up all the truth. No wonder I have a hard time finding useful log messages when I'm trying to troubleshoot something.
Tuesday, September 09, 2008
apt-cacher-ng
I have several machines on my network running Ubuntu Linux which need to be updated regularly to keep up with security updates and the like. Several months ago I decided to try using a caching proxy to get updates from the Ubuntu package repositories in order to reduce load on the Ubuntu servers as well as to speed up the updating process on my systems. After spending some time using apt-proxy, and being generally dissatisfied with its reliability, I decided to give apt-cacher-ng a try.
Unfortunately apt-cacher-ng's documentation is a bit inaccessible. Aside from not being available on the project's website (it's in PDF form in the documentation directory after you install it), the documentation, although complete, is kind of impenetrable. There also really isn't anything that I could find along the lines of HOW-TOs or FAQs on the 'tubes. I eventually got it worked out, and, at least for the common case, it turned out to be more straight-forward than the documentation leads you to believe. Here's how I set mine up.
I put entries in my acng.conf like the following:
Remap-ubuntu: http://us.archive.ubuntu.com/ubuntu
Remap-medibuntu: http://packages.medibuntu.org/
The way this works is you specify names for each Remap-[whatever] where [whatever] is whatever you want to call it--they just have to be unique. Then the part after the ':' is the literal URL of the repository you're caching including the directory path on that server, if there is one.
The documentation describes a third part that follows a ";". If your second part is the actual URL of the repository, you don't need the third part, as you see above.
In my sources.list, I put
deb http://my-server-name:3142/packages.medibuntu.org hardy free non-free
deb http://my-server-name:3142/us.archive.ubuntu.com/ubuntu hardy main restricted universe multiverse
Here, the URL to the apt repositories is your local server name (port is 3142 unless you change it in acng.conf) followed by a directory that is the exact same as whatever the fully qualified domain name of the real apt repository was, followed by the actual directory path that you appended to the actual apt repository in your acng.conf.
There are lots of other options described in the apt-cacher-ng documentation, but I believe this is the common case, and it's working fine so far.
Update:
The directory structure that gets created under /var/cache looks like:
Unfortunately apt-cacher-ng's documentation is a bit inaccessible. Aside from not being available on the project's website (it's in PDF form in the documentation directory after you install it), the documentation, although complete, is kind of impenetrable. There also really isn't anything that I could find along the lines of HOW-TOs or FAQs on the 'tubes. I eventually got it worked out, and, at least for the common case, it turned out to be more straight-forward than the documentation leads you to believe. Here's how I set mine up.
I put entries in my acng.conf like the following:
Remap-ubuntu: http://us.archive.ubuntu.com/ubuntu
Remap-medibuntu: http://packages.medibuntu.org/
The way this works is you specify names for each Remap-[whatever] where [whatever] is whatever you want to call it--they just have to be unique. Then the part after the ':' is the literal URL of the repository you're caching including the directory path on that server, if there is one.
The documentation describes a third part that follows a ";". If your second part is the actual URL of the repository, you don't need the third part, as you see above.
In my sources.list, I put
deb http://my-server-name:3142/packages.medibuntu.org hardy free non-free
deb http://my-server-name:3142/us.archive.ubuntu.com/ubuntu hardy main restricted universe multiverse
Here, the URL to the apt repositories is your local server name (port is 3142 unless you change it in acng.conf) followed by a directory that is the exact same as whatever the fully qualified domain name of the real apt repository was, followed by the actual directory path that you appended to the actual apt repository in your acng.conf.
There are lots of other options described in the apt-cacher-ng documentation, but I believe this is the common case, and it's working fine so far.
Update:
The directory structure that gets created under /var/cache looks like:
apt-cacher-ng
|-- canonical-partner
| `-- dists
| `-- hardy
|-- ubuntu
| |-- dists
| | |-- hardy
| | |-- hardy-backports
| | `-- hardy-updates
| `-- pool
| |-- main
| |-- restricted
| `-- universe
`-- ubuntu-security
|-- dists
| `-- hardy-security
`-- pool
|-- main
|-- multiverse
`-- universe
Tuesday, January 01, 2008
Wednesday, December 15, 2004
The Shadow File
This is the first post to The Shadow File. I suppose a brief explanation is in order. What is The Shadow File? In Unix and Linux, an algorithm is used to create a one-way hash of a user's password. This hash, along with the username and other information used to be stored in /etc/passwd. In many modern *nix systems, the password hash has been removed from the passwd file and is now stored in a separate file, because the passwd file is world-readable. This way, an attacker would have to obtain both files in order to attempt to recreate the password. The file that contains the password hashes is /etc/shadow. Now you know.
The things that will fill this page include my humble observations and musings on whatever projects I may be working on or anything at all that may stimulate my thoughts. So prepare to have your attention captured. I'm sure you won't be able to pry your eyes away.
The things that will fill this page include my humble observations and musings on whatever projects I may be working on or anything at all that may stimulate my thoughts. So prepare to have your attention captured. I'm sure you won't be able to pry your eyes away.
Subscribe to:
Posts
(
Atom
)