~chuck/blog

While attempting to build HAL on Beyond Linux From Scratch (Currently the SVN version, scheduled to be the 6.4 release), I came across this error:

probe-storage.c: In function ‘main’:
probe-storage.c:462: error: dereferencing pointer to incomplete type
probe-storage.c:462: error: ‘VOLUME_ID_FILESYSTEM’ undeclared (first use in this function)
probe-storage.c:462: error: (Each undeclared identifier is reported only once
probe-storage.c:462: error: for each function it appears in.)
probe-storage.c:463: error: dereferencing pointer to incomplete type
probe-storage.c:463: error: ‘VOLUME_ID_RAID’ undeclared (first use in this function)
probe-storage.c:464: error: dereferencing pointer to incomplete type
probe-storage.c:464: error: ‘VOLUME_ID_OTHER’ undeclared (first use in this function)
probe-storage.c:465: error: dereferencing pointer to incomplete type
probe-storage.c:465: error: ‘VOLUME_ID_CRYPTO’ undeclared (first use in this function)

After some looking around, I had almost given up hope when I decided to take a look at /usr/include/libvolume_id.h where the particular VOLUME_ID structs are created. I also Googled for that file name, and came across koders.com’s enumeration of header files. The file listed on their site was 116 lines, and the file installed on my LFS box was only 54, and didn’t include the structs for the items listed in the above error.

After making a backup of the original libvolume_id.h file, I copied the file from koders.com (which, incidentally, is from CentOS) and catted it into place on my server.  I ran the compile for HAL again, and now enjoy the sweet and slightly spicy flavor of success.

Hoorah.

/cs

This nearly scared the life out of me:

[chuck@thom ~]$ gpg -v
Warning: using insecure memory!
gpg: Go ahead and type your message ...

I was on a FreeBSD virtual machine, and had just installed GnuPG.  As it turns out, I rtfm’d and found the solution:

In the “BUGS” section of the gpg(1) man page:

On  many systems this program should be installed as setuid(root). This is necessary to lock memory pages. Locking memory  pages  prevents  the operating   system   from  writing  memory  pages  (which  may  contain passphrases or other sensitive material) to disk. If you get no warning message  about  insecure  memory your operating system supports locking without being root. The program drops root privileges as soon as locked memory is allocated.

Here are the steps I took to make the gpg2 binary setuid:

$ which gpg
/usr/local/bin/gpg
$ ls -lah /usr/local/bin/gpg
lrwxr-xr-x  1 root  wheel     4B Feb  3 04:36 /usr/local/bin/gpg -> gpg2
$ chmod 4755 /usr/local/bin/gpg2
$ ls -lah /usr/local/bin/gpg2
-rwsr-xr-x  1 root  wheel   576K Feb  3 04:36 /usr/local/bin/gpg2

So, sure enough, after setting the gpg2 binary to be setuid, everything worked:

[chuck@thom ~]$ gpg -v
gpg: Go ahead and type your message ...

Now I can safely, securely use gpg on FreeBSD.

/cs

I came across an issue where a customer needed education on using Redirect in the Apache config.  Particularly, the redirects were being configured through webmin (which, btw, does an amazing job of mangling the httpd.conf file!).  I though somebody may find it useful, and cleaned it up.  The names or websites have been changed to protect the innocent or the not-so-innocent.

Here is the syntax that webmin placed into the Apache config on your server for various redirects:

# grep ^Redirect /etc/httpd/conf/httpd.conf
Redirect http://kubrick.fruella.com “https://secure3.paymelater.net/csr/default.asp”
Redirect http://kubrick “https://secure3.paymelater.net/csr/default.asp”
Redirect http://epay.fruella.com “https://secure3.paymelater.net/fruella/”
Redirect http://epay.fruelladev.com “https://secure3.paymelater.net/fruella/”
Redirect http://epay “https://secure3.paymelater.net/fruella/”
Redirect 301 epay “https://secure3.paymelater.net/fruella/”
RedirectPermanent epay “http://www.gooboodle.com”
RedirectPermanent e-pay “http://www.gooboodle.com”

These will not work:

Redirect http://kubrick “https://secure3.paymelater.net/csr/default.asp”
Redirect http://epay “https://secure3.paymelater.net/fruella/”
Redirect 301 epay “https://secure3.paymelater.net/fruella/”
RedirectPermanent epay “http://www.gooboodle.com”
RedirectPermanent e-pay “http://www.gooboodle.com”

The reason that these won’t work is because you aren’t giving them a URL or URI to redirect. A proper 301 redirect (which is the most common type, and properly what you need) is as such:

Redirect 301 / http://www.example.com

This will take the root of the site (”/”) and redirect it to www.example.com. So, if your site is domain.com, and you visit domain.com in a browser, you’ll be redirected to www.example.com. The URL in the browser will change, and a new request to Apache is made for www.example.com.

If you have a particular page that needs to be redirected, the syntax would be similar:

Redirect 301 /store/secure/checkout.php http://www.paymesometime.com/

… or something similar to that.

This will take requests for domain.com/store/secure/checkout.php and redirect them accordingly.

Through webmin, you want to configure these as follows:

The first case:

From: /
Status: 301
To: http://www.example.com

The second case:

From: /store/secure/checkout.php
Status: 301
To: http://www.paymesometime.com/

Alternatively, in the “From:” section, you can specify a full URL, similar to the “To:” section, but I would recommend that it is easier to read them if you differentiate the syntax.

As for the entries in your configuration, here is an outline of what’s incorrect:

Incorrect:
Redirect http://kubrick.fruella.com “https://secure3.paymelater.net/csr/default.asp”

Correction:
Redirect 301 http://kubrick.fruella.com “https://secure3.paymelater.net/csr/default.asp”

You have provided a URL to redirect from (you could substitute with “/” in this case, because it’s the base URI). You have specified a URL to redirect to. You have NOT, however, provided a status. If this rule is updated in webmin with a “Status:” of 301, then it will work.

Incorrect:
Redirect http://kubrick “https://secure3.paymelater.net/csr/default.asp”

Correction:
Redirect 301 http://kubrick.fruella.com “https://secure3.paymelater.net/csr/default.asp”

This is incorrect because there is no status and because http://kubrick is not a fully qualified domain name.

Incorrect:
Redirect 301 epay “https://secure3.paymelater.net/fruella/”

Correction:
Redirect 301 / “https://secure3.paymelater.net/fruella/”

All of the parts including From:, To:, and Status: are here, but “epay” is neither a URI (which begins with a “/” character) nor a fully qualified domain name.

Redirects will be evaluated top to bottom, so if you have more than one that matches (such as two that redirect from “/” to another URL) then only the first will be effective, and the second is unnecessary.

This should be enough to get you started with redirects in Apache.

/cs

. . . so i created myip.ozymo.com which does the same thing:

$ curl myip.ozymo.com
64.39.19.8

Sometimes it’s nice to get just the IP returned without all the fluff.

/cs

Hello, all!

I just had to clean out a Postfix queue, and came up with this little
oneliner:

for i in `postqueue -p | grep -B1 ‘450\|451\|452\|421\|server dropped connection\|Connection refused\|Connection timed out\|Host not found\| Blacklisted\|DELETED\|PTR\|reverse dns\|refused to talk\|No route to host\|while sending\|timed out\|timeout\|root’ | grep ^[0-9A-G] | cut -d’ ‘ -f1`; do postsuper -d $i; done

It really does the trick. Make sure that if you copy it above, you
check the input. Wordpress does some funny things to dashes and
whitespace sometimes.

/cs

The terms “755″ and “777″ can be a little confusing unless you are
familiar with UNIX permissions. These two items are octal notation
representing the bits set for particular permissions for each of “user”,
“group”, and “other”. Each digit corresponds to one of these.

Basically, permissions can be comprised of three numbers, which, when
added together, give you a permission in the range of 0-7. The three
numbers correspond to “read” (4), “write” (2), and “execute” (1)
permissions. As you can see, if a user, group, or other has all the
permissions, then the pieces, added together, equal to seven:

r + w + x = rwx
4 + 2 + 1 = 777

In UNIX, from the shell, when you look at a directory listing of a
particular file, such as the wp-content directory, you are presented
with an “rwxrwxrwx” notation of the permissions scheme (the leading “d”
signifies that this is a directory):

$ ls -lahd wp-content/
drwxr-xr-x 5 chuck chuck 4.0K Nov 25 11:15 wp-content/

As I mentioned, each digit in the “755″ notation corresponds to one of
“user”, “group”, or “other”. In essence, the permissions “755″
correspond as follows:

user—group–other
rwx____r-x____r-x
421____401____401 (or 4+2+1,4+0+1,4+0+1)
7______5______5__ (this is for visual sanity)

Essentially, when a directory is set to “755″, then only the user that
owns the directory (in the case of the wp-content folder on my server,
the user chuck) has permissions to “write”, or create files, modify
files, and remove files, from this directory. Members of the “group” and
members of “other” (meaning everyone else on the planet) can enter the
directory and read the contents of the directory.

In the case of “777″ permissions, anyone can “read”, “write”, or
“execute” a file or directory (executing a directory means entering it).

So, at this point we know how to tell who can or cannot write to a
directory. When someone browses to your website and tries to upload
content to the wp-content directory, they cannot.

The reason for this is because only the “user” owner of the directory
has “write” permissions. When a PHP script (which is what Wordpress is
comprised of) is parsed by the PHP engine on your site, it is done so by
the Apache service, which allows the client browser to contact your
server for exactly this purpose. The PHP script cannot “write” to the
wp-content directory because the script is being run as the “apache”
system user. Because the apache user is not the “user” owner of the
directory, and the permissions are “755″, the PHP script (running with
the apache user’s permissions on the directory) cannot “write” the
content to the directory.

Your desire to maintain server security is excellent! Most people don’t
realize that by giving the web server access to write to a directory
that they are opening up a security hole! In fact, many people change
the permissions to “777″ (world-writable) when they install Wordpress.

Wordpress is a very widely used blogging application. Generally, as long
as it is updated in a timely fashion, you can keep your
wp-content/uploads directory at 777 without worrying too much about
security, because the people at Wordpress have input validation in their
code to effectively prevent intrusion in that area. I still would not
advise it, but it shouldn’t cause a problem.

I must say though, do NOT simply change the permissions of the
wp-content directory to “777″. Make sure that it is only the “uploads”
directory therein. Changing the permissions of the wp-content directory
would also make the plugins directory world-writable, which WILL open a
vast security hole on your server.

I hope this information has been helpful!

/cs

Apache’s mod_rewrite is a whole universe of complexity of and to itself.

Suppose I have a URL that I want to redirect elsewhere:

http://www.ozymo.com/~chuck/home/tester.php?name=chuck&date=today

This PHP script doesn’t even exist on the server. This one does:

http://www.ozymo.com/~chuck/projects/mod/redird.html

So, I configure Apache to allow me to issue mod_rewrite directives in a
.htaccess file for that directory:

AllowOverride FileInfo

I bounce Apache, and put the following rewrite rules into a .htaccess file:

$ cat .htaccess
RewriteEngine on
#RewriteCond %{REQUEST_URI} ^/tester\.php$ [NC]
RewriteCond %{QUERY_STRING} ^name=chuck&date=today$
RewriteRule ^(.*)$ http://www.ozymo.com/~chuck/projects/mod/redird.html
[L,R=301]

As such, I am redirected here:

http://www.ozymo.com/~chuck/projects/mod/redird.html?name=chuck&date=today

I do not want that. I want to remove the query string from the URL. How
am I to do that? Good question, and the question gives us our answer:

I append a question mark to the end of the Substitution:

RewriteRule ^(.*)$ http://www.ozymo.com/~chuck/projects/mod/redird.html?
[L,R=301]

And voila, I’ve been redirected to the html page without an appended query
string. What a pain, that little question mark is!

/cs

I modified a neat little hack, borrowed from Linux Server Hacks
(O’Reilly), so that whenever I ssh into my server, I can monitor the load
from the title bar of the terminal I’m using.

So, here’s the hack, as the book presents it:

$ cat ~/bin/tl
#!/usr/bin/perl -w

use strict;
$|++;

my $host=`/bin/hostname`;
chomp $host;

while(1) {

open(LOAD,”/proc/loadavg”) || die “Couldn’t open /proc/loadavg: $!\n”;

my @load=split(/ /,);
close(LOAD);

print “\033]0;”;
print “$host: $load[0] $load[1] $load[2] at “, scalar(localtime);
print “\007″;

sleep 2;

}

As you can see above, this is a perl script that I’ve placed in my user’s
bin directory. I’ve chmod’d it to have executable permissions:

# chmod +x ~/bin/tl

Now, if I want to see the server load in the title bar whenever I log into
my server through SSH, all I have to do is add this line to my .bashrc:

tl&

This effectively runs the process and backgrounds it, leaving me at the
shell prompt. You can see the backgrounding here:

$ jobs
[1]+ Running tl &

Now, if I simply close the SSH session, the terminal will hang, because
it’s waiting on the tl process to finish. The perfect while loop in the
script causes this to never happen. So, I added this line to my
.bash_logout file in my home directory:

/usr/bin/killall tl

This will kill all running tl processes before closing the bash shell and
terminating the SSH session.

/cs

I’m sure that there are about 18 million people that already know how to
“Blog by Email”, and do it on a regular basis. But I just learned about
it, and thought I would share.

At this URL, there is a plethora of information for configuring this
“Blog by Email” setup. It took me about thirty-eight seconds to
implement:

http://codex.wordpress.org/Blog_by_Email

Basically, I navigated to Settings->Writing and scrolled all the way
down. Just above the credentials area for your mail account, it
provides three suggested usernames that you can use. Definitely, one
should use a random or “hidden” email address, because it will be less
likely that your blog will fill up with spam. Once the credentials were
put in place, I clicked “Save Changes” and navigated to the wp-mail.php
script, which told me I had an email. Then the test message (not this
one, the goofy one i removed; shame on me) appeared as the most recent
entry on my blog! Awesome!

“Blog by Email” allows me the freedom to update my blog from anywhere
without having to use my login credentials on some random computer.
Then again, I suppose I would have to login to my email anyway, but eh?
What’re ya gonna do, right?

I’ve found it sometimes cumbersome and difficult to post as frequently
as I would like because I would have to login and navigate around the
admin page, then retype everything when my browser crashes, etc. Now, I
can work at my pace, save a draft or two along the way, and write in
between work or play, because I always have my email client open.

You should give it a try too!

/cs

In Intrepid, the nvidia-settings application throws a segmentation fault when trying to write changes to the X config file in /etc/X11/xorg.conf.

A workaround I found on the net was to rename or remove the xorg.conf file.  I’m not certain why this is happening, but there’s an existing bug report on it.

/cs

UPDATE: A fix was released for the bug.

UPDATE 081205: Adding “AllowTcpForwarding” to the sshd_config and restarting SSH should enable port forwarding, as it is disabled by default.

–

I have installed OpenSolaris on my Gateway MT3705 notebook.  I know.  I must be a glutton for punishment.

I have a Dell desktop that I also use, and like to have my laptop be the “control center”.  I accomplish this by using Synergy through an SSH tunnel.  Today was the first time I tried to use OpenSolaris as the host for my Synergy setup.  And it failed miserably.

After some googling, I found out that the SSH package in OpenSolaris is broken.  It doesn’t allow for correct SSH tunneling.  Here are some links for reference.

I run Debian on my desktop machine at present.  I’ve run SSH tunnels between my laptop and desktop while both were running Debian.  No problem.  I’ve set up an alias in my .bashrc on each of my boxes so that I don’t have to type the whole command each time:

alias synsetup=’ssh -f -N -L 24800:host:24800 host && synergyc localhost’

Obviously, this assumes that the host and client are already correctly configured.  I’ve discussed this previously.

So, I compiled and configured synergy in OpenSolaris, and tried to run the synergys command: No problem.  It runs fine, and works great on it’s own, outside of an SSH tunnel.  I can connect from the client without issue:

$ ps -ef | grep synergys
chuck  1159     1   0 19:44:13 ?           0:00 synergys

$ netstat -an | grep 24800
*.24800              *.*                0      0 49152      0 LISTEN
10.6.101.176.24800   10.6.101.174.38334    9088      0 49232      0 ESTABLISHED

But, running Synergy all alone transmits information between the two host over the network in plain text.  So, it’s best to run Synergy through an SSH tunnel.

Here’s a smattering of what I get when I follow the instructions from Synergy’s site on setting up the client through an SSH tunnel:

$ synergyc -f localhost
INFO: synergyc.cpp,716: Synergy client 1.3.1 on Linux 2.6.26-1-686 #1 SMP Thu Oct 9 15:18:09 UTC 2008 i686
DEBUG: CXWindowsScreen.cpp,841: XOpenDisplay(”:0.0″)
DEBUG: CXWindowsScreenSaver.cpp,339: xscreensaver window: 0×00000000
DEBUG: CXWindowsScreen.cpp,111: screen shape: 0,0 2560×1024 (xinerama)
DEBUG: CXWindowsScreen.cpp,112: window is 0×03400004
DEBUG: CScreen.cpp,38: opened display
NOTE: synergyc.cpp,330: started client
channel 2: open failed: administratively prohibited: open failed
NOTE: synergyc.cpp,276: disconnected from server
. . . (until Ctrl-C)
^CDEBUG: CScreen.cpp,49: closed display
NOTE: synergyc.cpp,408: stopped client

So, I googled the error message.  The first link shed some light. I dug farther, and found the links I posted above.

So, tunneling is broke on OpenSolaris, but works fine on Debian.  Why not reverse it? I set up this alias on my OpenSolaris laptop, to start the Synergy server.  It creates a reverse tunnel to the desktop machine, which runs Debian:

synserver_setup=’/usr/local/bin/synergys && ssh -f -N -R 24800:localhost:24800 chuck@client’

The only thing that’s different is the direction from which the tunnel is created.  To tunnel from the client to the server from the client, the ‘-L’ flag is used to create the local tunnel.  To tunnel from the client to the server from the server, the ‘-R’ flag is used to create the remote tunnel.  All set.

/cs

I have a few low-level development projects I want to undertake, and am working on building up my skills in systems programming. So, what better OS to use for a base than Linux, right? However, the Linux kernel is substantially large, and right now, I need to focus on trying to learn fundamental OS programming skills. I think it would be better to start with a smaller base system. Since Linux was written in and based on Minix, I figure I’ll give that a go. Here’s a short walk-through on installing the system in VirtualBox on a Debian Lenny host. Enjoy!

I assume that you already have a VirtualBox installation on your system and you know how to use it. I chose to use the 2.0.4 release of Minix, because the OS base grew substantially for version 3. You can download Minix 2.0.4 from here.

To start, create the VirtualBox guest. I called it, creatively, “Minix 2.0.4″. You can call yours what you like. I created a new virtual disk of 512M, which is much more than is necessary to install Minix, but will give me plenty of room to dick around.

Before booting, configure your Minix VM to boot from a floppy image. Navigate to the directory created when you extracted the Minix tarball, then to the i386 folder therein. You’ll see that there is nothing there. Tell VirtualBox to look for all files, rather than .IMG files. You’ll see the ROOT.MNX and USR.MNX files in your directory. For boot, we need to select the ROOT.MNX file.

Boot the machine. Press =, as it says, to start Minix. You’ll be prompted for a location of a device to use for mounting /usr. Unmount the floppy, as the root floppy is now loaded into RAM, by clicking Devices->Unmount Floppy on the VirtualBox window. Select Devices->Mount Floppy->Floppy Image… and navigate to the USR.MNX file we saw before. In Minix, finish the line with fd0 so that the device listed is /dev/fd0. Hit return, and you should be prompted with a login message. Above this, Minix explains that to install, you need to issue the setup command. Ignore this. We’re going to use the included documentation, and do things manually. What a concept!

In the extracted folder from the Minix tarball, you’ll find a file called usage.txt. This file contains both “automatic” and “manual” installation instructions for Minix. Open the file in your favorite editor. I use vi.

Scroll down to section 6. MANUAL INSTALLATION. These are the instructions we will use to install Minix. Sort of.

First things first, type root at the login prompt to log in as the root user.

Now, issue the part command to start the disk partitioner. For help in part, type ?. I scrolled using the arrow keys to the Kb column, and typed in the entire disk size, since we are not going to partition a VM. How silly would that be? Type the > key on the newly created partition to create the “subpartition” scheme. This is much like partitions inside a FreeBSD slice, except Minix refers to them as slices inside a partition It’s all semantics. I created partitions as follows:

Size in K Partition Description
1440 My Root partition, to be mounted as /.
10240 Partition to mount at /usr.
2880 Swap.

This creates just under 15M of partition space for use on the Minix system, and leaves just under 500M available on the slice I initially created. There is no need to reboot at this time, as the disk driver reloads the partition tables on the next access if the disk is not in use. Since we haven’t mounted anything, we’re good to go. Remember that the numbering for the disk starts at zero, i.e., our first partition is /dev/c0d0p0, and our first slice is /dev/c0d0p0s0.

Set the new slice as bootable by issuing the following command:

# installboot -m /dev/c0d0p0 /usr/mdec/masterboot

Create your swap space, and turn it on:

# mkswap /dev/c0d0p0s1
# mount -s /dev/c0d0p0s1

Now, we will create a filesystem for the /usr partition on /dev/c0d0p0s2:

# mkfs /dev/c0d0p0s1
# readall -b /dev/c0d0p0s1 | sh
# mount /dev/c0d0p0s1 /mnt
# cpdir -v /usr /mnt

This will copy all of the data from the floppy-mounted /usr partition to the /mnt directory, where the disk-mounted /usr partition resides. You can now mount the new /usr directory instead of using the floppy:

# umount /dev/c0d0p0s1
# umount /dev/fd0
# mount /dev/c0d0p0s1 /usr

This is where things get a little hairy. In the usage.txt file, we are instructed to switch back to the ROOT.MNX image to make the root partition and fill it with data. But, if you switch back to the ROOT.MNX image in VirtualBox, and mount it as follows, you can look in the /mnt directory with ls and see that there are some problems:

# mount /dev/fd0 /fd0

So, if the ROOT.MNX image won’t work now, what do we do? Reboot! Type halt at the prompt, and the system will move to the fd0> prompt. Go ahead and power off the virtual machine, or type exit and reset the box through VirtualBox. Then start it back up. Make sure you are booting from the ROOT.MNX image.

When prompted for a device to mount as /usr, simply provide the device we filled earlier, /dev/c0d0p0s1. Again, log in byt typing “root” at the login prompt. From here, we can move on from the instructions in usage.txt:

# mkfs -i 512 /dev/c0d0p0s0
# mount /dev/fd0 /fd0
# mount /dev/c0d0p0s0 /mnt
# cpdir -v /fd0 /mnt
# umount /dev/fd0

You can issue ls /fd0 after mounting it, and see that the file names are correct, unlike they were previously.

The /mnt/etc/issue file (or /etc/issue, when the device is mounted as root) creates the “use setup” line when the system boots, so it can be removed, or replaced with one of your choosing. The /mnt/etc/fstab file (or /etc/fstab, when the device is mounted as root) needs to be modified to reflect the new partitions. I used sed and cat to make my edits:

# sed ’s/t=unknown/t=\/dev\/c0d0p0s0/;s/r=unknown/r=\/dev\/c0d0p0s1/’ \ /mnt/etc/fstab > /mnt/etc/fstab.new
# cp /mnt/etc/fstab.new /mnt/etc/fstab
# cat >> /mnt/etc/fstab << EOF
> swap = /dev/c0d0p0s2
> EOF

Now unmount the new root partition and make it bootable:

# umount /dev/c0d0p1s0
# installboot -d /dev/c0d0p1s0 /usr/mdec/bootblock boot

Now we’re all set! Simply issue halt again, as before, and reboot the machine. Don’t forget that you need to unset the boot floppy device, or change the boot order in VirtualBox to have it boot from the hard disk.

Use your new system wisely!

/cs

Mosso, the Cloud Hosting offering from market-leading hosting provider Rackspace, has received a rave review about their on-the-fly scalability under load.

Mosso is a hosting platform that allows you to be flexible with your configuration. Their Linux offering includes PHP 4 & 5, MySQL 4 & 5, Ruby on Rails, Perl, and Python technologies for building your application. Their cloud is, from their website, “an advanced, enterprise-level hosting platform that beats the pants off of running your own servers – and scales easier, too.”

The platform is easy on the budget, too. I’d rather not talk numbers here, so, contact Mosso for more information!

/cs

I have a laptop that I use as my primary computer, and a desktop machine that I attach it to at work (both run linux).  I use synergy to connect the two so that I don’t have to remember which mouse is attached.

By default, synergy is quite insecure.  On the contrary, running synergy inside an encrypted ssh tunnel is quite secure.

I have two machines:

1. My laptop: synclient
2. My desktop: synserver

So, I use the keyboard/mouse from the desktop to control everything.  I assume that you are already aware of synergy and that you already have a working config.  Oh, ant that you are running Linux.  Oh, and that both of your Linux machine name the other one in their /etc/hosts files.  Oh, and that you have your synergy config in /etc/synergy.conf.  Now we don’t have to have everything all cluttered with flags.

There is no guaranty here that any of this will work on or improve the security of Windows.  You’ve been warned.

I log into both machines, and start up the synergy server on my desktop (I have a synergy.conf in /etc, so there is no need to pass it a config file argument with -c):

chuck@synserver:~$ synergys

I then log into my laptop, and do the following:

chuck@synclient:~$ ssh -f -N -L 24800:synserver:24800 synserver
chuck@synclient:~$ synergyc localhost

Now, it’s a pain to have to do that every time.  So, I put an alias in my ~/.bashrc:

alias synclient=’ssh -f -N -L 24800:synserver:24800 synserver && synergyc localhost’

Now, I can log into my laptop, once I’ve started synergys on the desktop, and run this:

chuck@synclient:~$ synclient

Now, the SSH tunnel has been configured, and the synergyclient started, all in one command.  No mess, no fuss. No password leaked on the net.

/cs

This tutorial will set up a basic virtual user config for vsftpd on a RHEL5-based system.  I recommend that you make backups of existing config files before implementing this solution, in case you need to revert.  This allows virtual “guest” users to log in with individual usernames and passwords and have access to a base directory.

I suggest building the initial files in a directory of their own first, and the steps below outline copying the files into place.

Six simple steps:

Step 1: Create the virtual user database.

Create a text file with each username/password pair on two lines, i.e:

# cat /etc/logins.txt
username
password
username2
password2

Then, use BerkleyDB to has the file, and change its permissions:

# db_load -T -t hash -f logins.txt /etc/vsftpd_login.db
# chmod 600 /etc/vsftpd_login.db

Step 2: Create a PAM file which uses your new database.

# cat > vsftpd.pam
auth required /lib/security/pam_userdb.so db=/etc/vsftpd_login
account required /lib/security/pam_userdb.so db=/etc/vsftpd_login

# cp vsftpd.pam /etc/pam.d/vsftpd

Step 3: Set up the location of the files for the virtual users by creating a “wrapper user”.

# useradd -d /home/ftpsite virtual

Step 4: Create your vsftpd.conf config file.

# cat > vsftpd.virtusr.conf
anonymous_enable=NO
local_enable=YES
write_enable=NO    # change to YES if you want uploads available
anon_upload_enable=NO
anon_mkdir_write_enable=NO
anon_other_write_enable=NO
chroot_local_user=YES
guest_enable=YES
guest_username=virtual
listen=YES
listen_port=10021    # optional
pasv_min_port=30000    # optional
pasv_max_port=30999    # optional

# cp /etc/vsftpd.conf /etc/vsftpd.conf.orig
# cp vsftpd.virtusr.conf /etc/vsftpd.conf

Step 5: Restart vsftpd.

# /etc/init.d/vsftpd restart

Step 6: Test.  I think you can figure this one out on your own.

Hold on to the logins.txt file, and simply update it and rebuild the DB when you need to add a user.  This allows several users access to the same directory and files.  Only give access to people you trust.

/cs