Usually when a URL of one of my repositories changes I either have all of my code checked in so I can grab a fresh copy or I am on a Windows machine and I can do it quickly in TortoiseSVN. Tonight I was working with a local repository (file://) and both it and the working copy had been on a Linux laptop so the location of the repository was a bit different and I had code that was not checked in before the move. So I was going from file:///home/user/repos/xyz to file:///Users/user/Repos/xyz and here is the command that allowed me to change the repository URL and commit my code.

svn switch --relocate file:///home/user/repos/xyz file:///Users/user/Repos/xyz

Then you can run your commit command or update command and all is well.

This afternoon a friend mentioned how annoying the whole deal with drive makers going by 1000 vs 1024 for sizes. In a way it does suck that they are using a system that is different from how a file is sized, but at the same time you should just start remembering the formatted size of a drive. Here is the list I had on my personal blog from long ago, it details the a good number of drive sizes. Calculations were based on (Drive GB x 1000000000) / (1024×1024x1024). I do get sorta tired of the complaint only because if someone really has the time and energy to bitch about something so small they haven’t spent enough time dealing with standards, guidelines and compliance in the technology world to realize that this is just an inconvenience and not really a big enough one to complain about.

   4 =   3.73              120 =  111.76
 4.3 =   4.00              147 =  136.90
   9 =   8.38              150 =  139.70
  10 =   9.31              160 =  149.01
  18 =  16.76              180 =  167.64
  20 =  18.63              200 =  186.26
  30 =  27.94              250 =  232.83
  36 =  33.53              300 =  279.40
36.4 =  33.90              320 =  298.02
36.7 =  34.18              400 =  372.53
  40 =  37.25              500 =  465.66
  60 =  55.88              640 =  596.05
  74 =  68.92              750 =  698.49
  80 =  74.51             1000 =  931.32
 100 =  93.13             1500 = 1396.98

Update: I just thought about binding to a specific address to help prevent others from being able to ssh into a server. This is similar to changing the port except that there are a limited number of ports, you could bind to xf1er.domain.com and it would be forever before someone was able to brute force the address alone unless the DNS servers allowed zone transfers. The best solution is to probably use a dedicated IP address for ssh, one that nothing else is using and that nothing can resolve to. The reason is that say you had set ListenAddress to xf1er.domain.com if that resolves to the same IP as domain.com or www.domain.com it will still let you ssh in. It is not like setting the address for a particular site in Apache, where it will actually need to match the domain name.

Recently someone on the SoCal LinuxUsers mailing list was asking for information, a checklist or sorts on procedures to lock down your Linux box when putting it on the big bad internet. I will probably collect a lot more of these and make a real checklist, but this will get you started. Note that some of the configuration directives for OpenSSH are already set by default, I prefer to make the change in the config file anyway to ensure those things are set. You never know when an error might occur in an update and something could have been maliciously changed in the code or an accident happened.

• Install and Configure DenyHosts

  DenyHosts will add hosts to your /etc/hosts.deny file based on criteria you set and if you like it can download a file which is updated with hosts currently violating DenyHosts policies on other machines. For a lot of services you have to run them in xinetd or inetd for TCP wrappers to work, without TCP wrappers being involved in the daemon hosts.deny/hosts.allow will do nothing for you. The alternative to xinetd and inetd being involved is support for the libwrap library, which most OpenSSH packages have built in when compiled. You can check if a daemon has libwrap support by following the guide on ducea.com ((How to find out if a daemon was build with TCP Wrappers support)).

  All about Linux has a good post explaining how to use TCP wrappers to secure Linux ((All about Linux: Using TCP Wrappers to secure Linux)).

Read the rest of this entry »