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.
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
)