Setting up a Subversion Server on Ubuntu
From the “So I can find it again” department…
From the “So I can find it again” department…
A friend just got her computer back from “the computer doctor.” Evidently it had been compromised with a root kit (the really nasty sort of software that runs at such a low-level your anti-virus software can’t see it). She uses three different anti-malware tools and was quite surprised that none of them caught it.
The problem with anti-virus software is it can only protect you against problems that are already known. The bad guys are constantly looking for new ways to attack your computer and the anti-virus programs are playing catch up. I’m not saying don’t use anti-virus software (the free version of Avast has saved me several times), just don’t count on it as your only defense.
So, is there any 100% guaranteed way to stop malware? Well, you could always unplug your computer from the Internet and never use it to access any USB drives or CDs, but that’s not exactly practical. And if you do stay online, even visiting only “known safe” sites doesn’t help much, since even legit sites get compromised on occasion.
But there are a few things you can do to help your odds. None of these approaches is 100% guaranteed to keep you safe, but they should help.
This is “the usual stuff” you hear any time someone talks about how to stay safe online. It seems obvious, and yet it bears repeating because it’s easy to get careless:
Beyond the basics, there are a few other things that are easy enough to do, but don’t always make it into the “How to stay safe” discussions. Most attacks against your computer are targeting the applications you run, not the operating system. (Running Windows isn’t as risky as reading a PDF file with Acrobat reader.)
Security journalist Brian Krebs talks a bit more about keeping software up to date and what to install or delete in his: 3 Basic Rules for Online Safety
Wanna go really hard-core?
There are no magic bullets. None of these suggestions will provide absolute protection for all users. What might be overkill for one person’s situation might not be nearly enough protection for another. But by choosing the practices which make the most sense for you personally, you can tilt the odds a bit more in your favor.
In most discussions of online security, someone inevitably replies “Get a Mac!’ or “Switch to Linux.” It’s a bit like going to a concert and someone yelling, “Play Freebird.” It’s a wonderful song, and a few groups have done great covers in response, but it’s not always the best fit.
But if the suggestion is inevitable, I may as well be the one to make it and bring up some of the tradeoffs.
Switching to a Mac may actually make sense for some folks, but don’t make the switch thinking you’ll be invincible. At the annual CanSecWest security conference, there’s a “Pwn2Own” contest where security professionals attempt to break into computers running the latest versions of the Mac OS, Windows and Linux. The first one to succeed, wins the computer. Every year, the Mac is the first system compromised.
Now that’s what happens at a security conference. Macs are less common than Windows computers; so the bad guys have to work harder to find them. It’s much easier to attack the more common computers.
But malware targeting Macs has been cropping up too.
Other concerns with switching to a Mac:
Linux tends to be the most secure OS of all (as noted earlier, most of the problems these days are the software you run on top of it). The main downfalls of Linux are:
“The great thing about standards is that there are so many to choose from.” — Me.
I’m pretty sure this is why:
(via xkcd)
After converting the PogoPlug to run arbitrary programs, I was able to install subversion and manually run svnserve as a daemon (it’s in the manual, just run “svnserve -d”), but having to remember to do that after every boot is a nuisance.
A Google search for install svnserve as a daemon turned up instructions for setting up svnserve on Ubuntu, as well as a few scripts. Obviously PlugBox Linux isn’t Ubuntu, but it was a step in the right direction. Installing httpd during the initial PogoPlug hack had already introduced me to the /etc folder, the rc.conf file, and the rc.d subfolder.
Poking around in rc.d, I discovered the httpd startup script. So now I knew where my svnserve script needed to go. The Ubuntu setup instructions included several helpful bash scripts in the comments, my next step was to run “view httpd” and verify that it was also a bash script. Knowing that, I could just use the new script verbatim.
Then I listed the files in /etc/rc.d and discovered that one of them was named svnserve. Sonuvagun, the svn package included a script!
So in the end, all I had to do was go to /etc and edit rc.conf. The very last line in the file is DAEMONS=(…..). All I had to do was add svnserve to the list.
Well… that was actually the next to last thing.
After rebooting (“shutdown -r now”), TortoiseSVN would connect to the svn server, but it couldn’t find my repository at svn://plugbox/test. I’d forgotten that by default, svnserve serves up repositories in any directory on the entire machine. My test repository was now located at svn://plugbox/media/external_drive/Subversion/test.
To go back to a short URL, I went to /etc/conf.d, edited svnserve, and set
SVNSERVE_ARGS=”-r /media/external_drive/Subversion/”
Next I ran
/etc/rc.d/svnserve stop
followed by
/etc/rc.d/svnserve start
and voila! My repository was back at svn://plugbox/test
I’ve had a PogoPlug for a little more than a year.
The pluses to the device are:
There are some down sides too:
All in all, it’s an interesting device and I can definitely see where home users might find it useful if they’re comfortable with the fact that you need to login via a third-party service (the My PogoPlug service), even when you’re accessing it a home. (If Cloud Engines ever goes out of business, PogoPlug owners may find themselves with an unusable device.)
Part of my reason for acquiring the PogoPlug in the first place was that it seemed like a potentially inexpensive way to accomplish a few things on my home network:
Goal 1 was easy enough to accomplish straight out of the box. Goals 2 and 3 were going to take some work.
When I finally decided to hack the PogoPlug, a Google search led me to LifeHacker’s tutorial on turning the device into a “Full-Featured Linux Web Server.” It was a good starting place, but in the end I decided to follow the source instructions from PlugApps.com. (CAUTION: As it says on the PlugApps instructions, hacking your PogoPlug will void the warranty.)
My initial install was onto a 4GB SanDisk Cruzer flash drive. The initial reboot came up fine, but later boots tended to come back to PogoPlug Linux, which after the first steps of the install would no longer connect to the MyPogoPlug service. If I manually mounted and mounted the thumb drive before running /sbin/reboot, that would take me over to PlugBox Linux, but going through those steps repeatedly is a pain. I reran the install for PlugBox Linux using a no-name 16GB drive and it’s been working reliably ever since (I love that storage has become so cheap that I had a 16GB drive “just laying around”).
To accomplish Goal #1 (file sharing), I installed Samba. It works like a champ and I’ve been able to back to doing my backups to a network drive.
To accomplish Goal #2 (private web sever), LifeHacker’s instructions did the job. By default, the web site is served out of /srv/http, and there’s also an ftp site in /srv/ftp.
Goal #3 took some guesswork. I didn’t see any mention of Subversion on PlugApps, but I made a guess and ran pacman -Sy subversion. I haven’t got around to setting up svnserve to run as a daemon at boot time, but it’s running right now. (Getting it set up as a daemon will require putting a script in /etc/rc.d/ and adding it to the list of daemons at the end of /etc/rc.conf.)
So mission accomplished. Not bad for a $100 device.
Choosing to go from 32-bit Vista to 64-bit Windows 7, also meant choosing to do a “custom” installation of Windows. Meaning that I have to reinstall all my programs.
Still more to be added over the next few days, but here’s what I’ve got so far.
The List:
General Computing
Internet Tools
Developer Tools
Permalink Comments off
I bit the bullet today and installed Windows 7 on my primary computer. All in all, it was a fairly painless process, though because I was switching from 32-bit to 64 (I can finally use that 4th GB of RAM!), I had to do a “custom” install which means I have to reinstall all my programs as well. For most purposes, it’s very much like moving to a new computer.
One of my gripes with Firefox and Thunderbird is that while the installers for both applications are very helpful about importing settings (passwords, network configurations, etc) from competing products, neither one provides a facility for migrating settings from your previous computer.
Fortunately, with a little bit of knowledge, it’s not overly difficult to do this by hand (which is probably why nobody – myself included – has written an appropriate migration tool).
Disclaimer: I don’t use many plugins, so I don’t know if or how well these steps will work with plugin settings. You’ll probably want to wait until after the migration before installing any plugins on the new system.
Start off by installing Firefox on the new computer, all we’re copying is the user settings, not the software installation. I recommend you make certain that both the old computer and the new one are running the same version of the browser. (I’m not certain this is completely necessary, but it’s better to be safe.)
Next, one the old computer, you’ll need to use Windows Explorer to visit the directory where Firefox stores its settings.
<username> is, of course, the username you use to log into the computer. (You can find this by going to a command prompt and typing “net config workstation”.)
The “Application Data” or “AppData” directory is usually hidden, so you may have to blind type the path into the Explorer address bar.
On the old computer, make a copy of the “profile.ini” file and the “Profiles” directory.
On the new computer, go the corresponding path on the new computer, delete the existing “profile.ini” file and the “Profiles” directory, and replace them with the copies you made from the old one.
Start off by installing Thunderbird on the new computer, all we’re copying is the user settings, not the software installation. I recommend you make certain that both the old computer and the new one are running the same version. (I’m not certain this is completely necessary, but it’s better to be safe.)
Next, one the old computer, you’ll need to use Windows Explorer to visit the directory where Thunderbird stores its settings.
<username> is, of course, the username you use to log into the computer. (You can find this by going to a command prompt and typing “net config workstation”.)
The “Application Data” or “AppData” directory is usually hidden, so you may have to blind type the path into the Explorer address bar.
On the old computer, make a copy of the “profile.ini” file and the “Profiles” directory.
On the new computer, go the corresponding path on the new computer, delete the existing “profile.ini” file and the “Profiles” directory, and replace them with the copies you made from the old one.
Permalink Comments off
From the writing-things-down-so-I-can-find-them department….
Selectors in a nutshell:
You can also group things like this…
div p.classname which would mean, ‘Anytime a div tag contains a p with class=”classname”, the p should be displayed according to this rule…’
Permalink Comments off
Sorry, I know this entry won’t mean much to many folks, but this seems like a useful reference to the DOM available from JavaScript.
This entry should allow me to find it again.
Permalink Comments off