Adding terminator or gnome-terminal to desktop pop-up menu list

To add programs to the Ubuntu Gnome desktop popup menu list (when you right-click on the desktop):

Inside ~/.gnome2/nautilus-scripts:

Create a script:

#!/bin/bash
cd $NAUTILUS_SCRIPT_CURRENT_URI
exec /usr/bin/terminator

sudo chmod 755 ~/.gnome2/nautilus-scripts/your_script_name

ps wauxg | grep nautilus
kill -HUP pid_of_nautilus

Nautilus will restart and you may lose control of your desktop for a short while. Just wait and be patient for it to start working again.

Right-click on the desktop and find your script ready to run from the ‘Scripts’ selector.

alternatively, you can install:

apt-get install nautilus-open-terminal

which will directly put a link to gnome-terminal inside the desktop popup menu list.


Comments   FreeBSD, Ubuntu, openSuse
Related posts:

Enabling Linux compatibility on FreeBSD

FreeBSD 7.1 kernel support for Linux emulation layer has gotten some nice updates. I like to use a better ‘top’-like utility called htop which runs as a Linux binary. Here’s how to get it set up on FreeBSD (am64 but works for i386 as well)

[Thanks to Domain of Aragon for outlining the steps]

Step 1: Enable Linux compatibility and linprocfs

Add linux_enable=”YES” to /etc/rc.conf.
Add compat.linux.osrelease=2.6.16 to /etc/sysctl.conf.
Add OVERRIDE_LINUX_BASE_PORT=f8 to /etc/make.conf.

Add this line to /etc/fstab:
linproc /usr/compat/linux/proc linprocfs rw 0 0

Then run these commands:

mkdir -p /usr/compat/linux/proc
mount /usr/compat/linux/proc
/etc/rc.d/abi start
/etc/rc.d/sysctl start

You will now need to install the following ports and their dependencies:

cd /usr/ports/emulators/linux_base-f8 && make install clean

After all this is done, /usr/ports/sysutils/htop port can be installed.


Comments   FreeBSD
Related posts:

FreeBSD 7.1 out today


Image via Wikipedia

The latest REL version of FreeBSD is out now.


Comments   FreeBSD
Related posts:

Forget ifconfig and route. Use iproute2 instead.

The legacy ifconfig and route commands can now be seen as being deprecated and be no longer used for setup of network configuration.

People who are comfortable using ifconfig and route will be fine with the new iproute2 suite, which provides similar functionality and improves upon the older net tools.

Here’s a short n’ sweet cheat sheet using iproute2 for network configuring.  If you want more in-depth information, go here.

Configure network card:
ip link set mtu 1500 dev eth0 (use mtu 9000 if on 1000M gigabit network for more efficiency)

Showing all network cards/IP information

ip addr show

Adding one or several IP addresses on network card.
The iproute2 suite doesn’t need fictitious interfaces such as eth0:1, eth0:2, etc.  This is legacy naming scheme for ifconfig. The ‘label’ will allow older ifconfig to be able to see all the addresses.
Using the CIDR notation with network prefix (after the slash) will automatically calculate the broadcast and netmask.
ip addr add 192.168.0.213/24 label eth0:1 dev eth0

Removing an IP address from network card
ip addr del 192.168.0.213/24 dev eth0

Adding default route
ip route add default via 192.168.0.1

Viewing routes
ip route show

Turning up/down network card
ip link set eth0 up
ip link set eth0 down


Comments   FreeBSD, Ubuntu, Web/Tech, openSuse
Related posts:

FreeBSD: for both Server and Client- Setting up SSH tunnel for FTP

This is the server and client configuration that you’ll need minimally in order to offer secure SSH tunnel for FTP clients.

This is useful for your FTP program that doesn’t have SFTP capabilities. The FTP program can take advantage of a SSH tunnel to securely connect to the FTP server.

inside /etc/hosts.allow :

# The rules here work on a "First match wins" basis.
# Let localhost users access any service on this box
ALL     : localhost 127.0.0.1 your_server_ip_address   : allow
# Let anybody with a RSA key in
sshd    : ALL                                                   : allow
# Everybody else can buzz off
ALL     : ALL                                                   : deny

Make sure this line is included at the end of /usr/local/etc/xinetd.conf

includedir /usr/local/etc/xinetd.d

in the file /usr/local/etc/xinetd.d/ftp

service ftp
{
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = root
        server          = /usr/libexec/ftpd
        server_args     = -llS

        disable         = no
}

Restart xinetd

/usr/local/etc/rc.d/xinetd restart

For your FTP client:
If you notice above in /etc/hosts.allow, FTP will only accept connections from the localhost on the server. 

(ALL     : localhost 127.0.0.1 your_server_ip_address   : allow) which is satisfied before hitting this line:

(ALL     : ALL                                                   : deny )

This means that you’ll need to start a SSH tunnel on your end that will allow a server local connection to the FTP port (21) on your behalf.

You can set up a such SSH tunnel like this:
Set up a SSH tunnel to SSH server on server_ip_address, port 22 with your private key.
During the configuring of the SSH tunnel,  set port fowarding using: local port of 8080 to port 21 on server_ip_address
Once you get the SSH tunnel going, start up your FTP program and connect to localhost on port 8080 and importantly, use PASSIVE mode!

Comments   FreeBSD
Related posts:

How to use Apache2 as a proxy for lighttpd to handle multiple Ruby on Rail applications

I’ve already explained how to set up multiple Ruby on Rails applications on a single domain using Lighttpd.  However, this assumes that you are only using lighttpd as your sole webserver.

However, if you have already been using the popular Apache2 webserver for many other applications and don’t want to give it up just so you can run Ruby on Rails applications.  It’s possible to use Apache2 for everything except for Ruby on Rail applications which can be automatically passed off to Lighttpd.

This can be simply done with 7 new lines in your Apache2’s httpd.conf (/usr/local/etc/apache22/httpd.conf for FreeBSD systems) and 2 minor modifications to your lighttpd.conf (/usr/local/etc/lighttpd.conf for FreeBSD systems).

In your lighttpd.conf:
change the server.port to 3000 and server.bind to “localhost”

Now is the time to restart lighttpd.

At the end of your httpd.conf:  (I had to change the VirtualHost lines so that the HTML codes wouldn’t be automatically filtered out by typepad)

‘<’  VirtualHost website.com * ‘>’
   ProxyRequests Off
   ProxyPreserveHost On
   ProxyPass /app1/ http://127.0.0.1:3000/app1/
   ProxyPass /app2/ http://127.0.0.1:3000/app2/
   ProxyPassReverse / http://127.0.0.1:3000/
‘<’ / VirtualHost  ‘>’

Restart your apache web server.

Go and rejoice in being able to use the best of both worlds!


Comments   FreeBSD
Related posts:

How to setup multiple apps on Ruby on Rails and Lighttpd

** UPDATE **
  I’ve also posted an entry on how to use Apache2 proxy to handle multiple Ruby on Rail applications on the same domain url.
** END UPDATE  **

One of the stranger things about Ruby on Rails is that after you have installed the basic software foundation to be able to run Ruby on Rail framework using lighttpd server with fast-cgi, the first application that you install via rails would be accessible only at the root url.

For example, if you had ran a ‘rails app1′, the url to access app1 would not be
http://website.com/app1/  , but rather http://website.com/

If you had set up another rails application called ‘app2′, you would have to stop lighttpd and change the lighttpd.conf to point to app2 before you could restart the lighttpd server and access app2 at the root url.

Many of the solutions I found on web to set up multiple ruby on rails applications also requires you to come up with a different domain for each application.  i.e.   http://app1.website.com and http://app2.website.com.  I didn’t really want to adopt this approach.

I would have much prefered to keep it all under a single domain (i.e. http://website.com/app1/ and http://website.com/app2/). It would make good sense if one could set up the appropiate configuration to avoid all this restarting and reconfiguring for multiple rails applications under the same domain url.

To my surprise, the online documentation and google search weren’t able to provide me with sufficient details to do this painlessly.  All the routing errors, 404s, 403s, 501s, and whatnots that I ecountered during countless configuration changes almost made me pull out my hair.  For a such simple and vital configuration, it sure wasn’t easy to figure out every last details that were necessary to get it all clicking together.

But, fortunately, after many false starts and dead-ends, I was able to figure all this out and here is what you need to do to be able to have multiple Ruby on Rails applications running under the same domain url (i.e. http://website.com/app1/ and http://website.com/app2 )

We need to set up lighttpd so that it is able to detect when app1 or app2 is on the url and pass the request off to the correct app fast cgi. You don’t want to strip-request-uri in this configuration since this configuration change needs the full url to function correctly.  Later, we will be adding a route change to ensure that the url path is correct for the entire hierachy of each app.

in your lighttpd.conf (/usr/local/etc/lighttpd.conf for FreeBSD systems), make these changes:

server.modules              = ( "mod_rewrite", "mod_alias", "mod_access", "mod_fastcgi", "mod_accesslog" )server.errorlog             = "/var/log/lighttpd.error.log"   # don't forget to chown www:www this fileindex-file.names            = ( "dispatch.fcgi", "index.php", "index.html", "index.htm", "default.htm" )accesslog.filename          = "/var/log/lighttpd.access.log"  # don't forget to chown www:www this file$HTTP["url"] =~ "^/app1/" {	server.document-root = "/usr/local/www/lighttpd/data/app1/public/"	alias.url = ( "/app1/" => "/usr/local/www/lighttpd/data/app1/public/" )	server.error-handler-404 = "/dispatch.fcgi"	server.indexfiles = ( "dispatch.fcgi", "index.html" )	fastcgi.server = ( ".fcgi" =>                           ( "localhost" =>                            (			      "min-proc" => 1,			      "max-proc" => 1,                              "socket" => "/tmp/app1-fastcgi.socket",                              "bin-path" => "/usr/local/www/lighttpd/data/app1/public/dispatch.fcgi",			      "bin-environment" => ( "RAILS_ENV" => "development" )#		   	      "strip-request-uri" => "/app1/"                            )                           )                         )}

$HTTP["url"] =~ "^/app2/" {	server.document-root = "/usr/local/www/lighttpd/data/app2/public/"	alias.url = ( "/app2/" => "/usr/local/www/lighttpd/data/app2/public/" )	server.error-handler-404 = "/dispatch.fcgi"	server.indexfiles = ( "dispatch.fcgi", "index.html" )	fastcgi.server = ( ".fcgi" =>                           ( "localhost" =>                            (			      "min-proc" => 1,			      "max-proc" => 1,                              "socket" => "/tmp/app2-fastcgi.socket",                              "bin-path" => "/usr/local/www/lighttpd/data/app2/public/dispatch.fcgi",			      "bin-environment" => ( "RAILS_ENV" => "development" )#		   	      "strip-request-uri" => "/app2/"                            )                           )                         )} 

Now we need to ensure that all the urls spit out by app1 and app2 controllers will include ‘app1′ or ‘app2′ at the beginning of the root url:

in app1’s routes.rb:

add this line:ActionController::AbstractRequest.relative_url_root = "/app1"above the line:map.connect ':controller/:action/:id'

in app2's routes.rb:add this line:ActionController::AbstractRequest.relative_url_root = "/app2"above the line:map.connect ':controller/:action/:id'

Finally, stop and restart lighttpd at this point and you should be able to access both apps now!

Comments   FreeBSD
Related posts:

Nice FreeBSD Ports search script (psearch)

psearch

A utility for searching the FreeBSD ports. It lets you specify a regular expression
for searching, can search the long description (pkg-descr file), or do an inverse match,
similar to grep -v.

Here’s an example that shows how it works:

$ psearch firefoxchinese/firefox-zh_CN    Firefox Simplified Chinese(zh-CN) Language Packchinese/firefox-zh_TW    Firefox Traditional Chinese(zh-TW) Language Packjapanese/firefox-ja      Firefox Japanese(ja) Language Packkorean/firefox-ko        Firefox Korean(ko) Language Packwww/adblock-firefox      A content filtering plug-in for Firefoxwww/bugmenot-firefox     Firefox extension to bypass compulsory web registrationwww/firefox              Web browser based on the browser portion of Mozillawww/firefox-remote       Wrapper scripts for firefox web browserwww/linux-firefox        Web browser based on the browser portion of Mozillawww/mozex-firefox        Mozex allows Firefox's users to use external programs for mail, news, etc.www/preferential-firefox GUI interface to view & edit all Firefox prefs

Download psearch-1.0.tar.gz

Technorati Tags:


Comments   FreeBSD
Related posts:

FreeBSD 6.0 and VMWare 5 – problems with calcru:

After upgrading my FreeBSD kernel from 5.4 to 6.0 inside my VMWare image, I noticed a huge increase of “calcru: runtime” errors.

I tried all the sysctl kern.timecounter.hardware values as well as some other sysctl settings to no avail.  It seems that VMWare really screws around with the virtual machine clock and causes the clocks to go out of sync often.

So I did what any respectable programmer would have done:  comment out the annoying message in the kernel and recompile the kernel. :-)

The printf is in /usr/src/sys/kern/kern_resource.c


Comments   FreeBSD
Related posts:

Automatic ssh tunnels

Automatic ssh tunnels
from this blog entry

also read this blog entry for more ssh config work

1.) You must make a ssh user connection that will not prompt you for a password.

// On the Client machine follow these steps exactly (I am logged in as root)

// Just hit Enter after each on these prompts
# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
c1:7b:fe:cc:32:9f:51:6b:0d:be:5c:6d:b0:94:b9:fc root@bordersmart

// COPY new the key the SSH Server

/* HERE I am using the SSH login as tunnel (this user would have to be of course created on the SSH Server machine. After the scp command you will have to give the password.

*/

# scp ~/.ssh/id_rsa.pub tunnel@sshserver.net:/home/tunnel/.ssh/authorized_keys2
Password:
id_rsa.pub           100% |******************************************|   226       00:00   

// Now try to login – THERE SHOULD BE NO PASSWORD PROMPT
ssh tunnel@sshserver.net

2. Script that automatically checks to see if the ssh tunnel is open – if not it starts it up.

// PHP script (need to have CLI enabled)

#!/usr/local/bin/php
$port   = 2401;
$ip     = "127.0.0.1";

$fp     = fsockopen($ip, $port);
if($fp):
        echo "Port $x open in $ip \n";
        fclose($fp);
else:
        echo "Port $x closed in $ip \n";
        $str="ssh tunnel@sshserver -L 2401:localhost:2401";
        exec($str);
endif;

?>

3. Edit crontab to make this script run every 20 minutes

# keeps a ssh tunnel open to the cvs server
0-59/20 * * * * root /root/tmp/check.tunnel.php

Technorati Tags:


Comments   FreeBSD
Related posts:

calcru: runtime went backwards using FreeBSD under VMWare

If you get “calcru: runtime went backwards” errors while using VMWare to run a FreeBSD OS system:
Add to your sysctl.conf:

kern.timecounter.hardware=TSC

link
Timecounter was using two
clocks, the VPC clock and the host system clock.  I chose the TSC clock as
it was reported as slower than the ACPI-safe clock.  I figured (guessed)
that it was better to use the slower clock as I have my VPC setup to use
less cpu when off-focus of the guest o/s”


Comments   FreeBSD
Related posts:

VMWare and high resolution console (VESA)

update 10.14.05:

(Thanks to Nikolas Britton from FreeBSD questions mailing list)

Your computer (VMware) doesn’t have a "proper" VESA BIOS and that is
why 800×600 raster text mode won’t work etc. FreeBSD 6 has this all
worked just put ‘allscreens_flags="MODE_279"’ in rc.conf for
1024×768… you can get a list of other modes supported by typing in
vidcontrol -i MODE (I think, can never remember :-)). if you want this
for FreeBSD 5.x then your going to have to manually patch your system,
but I have a simple script that will do it for you. somewhere around
here…… check for patch errors after you run the script.
————————————————–
cd /tmp
rm current-vesa_patch.tar.gz
fetch http://www.nbritton.org/uploads/current-vesa_patch.tar.gz
rm -r current-vesa_patch
tar -zxf current-vesa_patch.tar.gz
cd /usr/src/sys/dev/syscons
patch </tmp/current-vesa_patch/current-syscons.diff
cd /usr/src/usr.sbin/vidcontrol
cp /tmp/current-vesa_patch/current-vidcontrol.1 ./vidcontrol.1
cp /tmp/current-vesa_patch/current-vidcontrol.c ./vidcontrol.c
make && make install && make clean
—————————————————–
You still need to put in your kernel (both FreeBSD 5 and 6):
options VESA
options SC_PIXEL_MODE

and when you cvsup your src in FreeBSD 5 you will need to reapply the
patch, cvsup will overwrite the files becouse the cvs revision tags
don’t match up.

end update

The black magic of VMWARE and VESA:

I simply wanted a high resolution FreeBSD console PTYs running under VMWare.  It was surprisingly more complex than I expected:

When attempting to change screen resolution for a console in FreeBSD running under VMWare, I ran across this error message:

> vidcontrol -g 100×37 VESA_800×600
vidcontrol: cannot set videomode inappropriate ioctl for device

It seemed to me that VMWare was unable to init VESA correctly in console but strangely enough Xorg is capable of changing to a higher resolution without any problems.

After some googling:

   VESA driver in current source tree checks the NONVGA flag
   of VESA information block when loading. If this flag is set
   it will refuse to initialize. Most VESA adapters do not set
   this flag, but the virtual display adapter in VMWare does.
   As a result VESA cannot be used on VMWare.

in src/sys/i386/isa/vesa.c, there is a check for the flag V_NONVGA in line 655.
If you comment it out, flag check will be bypassed.  After all, if Xorg can use higher resolution, there shouldn’t be a problem using VESA on the console!

Re-compiling my kernel to include the below as suggested by several more web searches:

options VESA
options SC_PIXEL_MODE
options VGA_WIDTH90

rebooting then:
> vidcontrol -g 100×37 VESA_800×600
vidcontrol: operation not supported by device

Arrrgghhhh!  Any more tips for me?


Comments   FreeBSD
Related posts:

increasing free space on your FreeBSD hard drive

If you are hurting for more disk space on your FreeBSD system, try the two commands below:

Cleaning up the working directories of your ports by doing:
portsclean -C

Remove any unreferenced distfiles by doing:
portsclean -D


Comments   FreeBSD
Related posts:

How to manually upgrade Twiki on FreeBSD

There is a new FreeBSD port of TWiki (twiki-20040904).  If you have already invested a lot of time creating documentation on your wiki, you certainly don’t want to do a portupgrade. That would destroy your wiki and force you to start over from scratch.

You need to install it manually in order to preserve your body of work. It was pleasantly easy to do this task.  I’m recounting the steps below so you can perform the same thing on your server.

Instead of portupgrading which will destroy the existing wiki, just download the file and take it from there.

Getting the file:
cd /usr/ports/distfiles
lynx http://twiki.org/getpackage.html
use arrow keys to scroll down to the link for the twiki-20040904.zip file
hit the ‘d’ key to download the zip file to current directory (Save File)

Getting the upgrade ready:

cd ~/
mkdir twiki
cd twiki
cp /usr/ports/distfiles/twiki-20040904.zip  .
unzip twiki-20040904.zip

Upgrading:
When you run the UpgradeTwiki script, you need to tell it where to put all the new twiki files.  The script will NOT alter the existing twiki files.  Instead, it will take the current twiki files and merge it with the new files and put the new files in another directory.  Once you confirm the merge, you can copy it over the exisiting twiki.

cd ~/twiki
./UpgradeTwiki /usr/local/www/new_twiki

Here, you’ll see messages scrolling by as it does the merging automatically.  The script may ask you some questions which were really easy to answer.

With the merging done in the /usr/local/www/new_twiki, you’ll need to make a backup copy of current wiki, just in case something goes wrong.
cd /usr/local/www
tar -cvf old-twiki.tar twiki
gzip old-twiki.tar

Now we can copy all the new twiki files over the old one:
cd new-twiki
cp -R * ../twiki

Now test the twiki on the web to make sure everything looks good!  If so, then can rm -rf /usr/local/www/new_twiki

Updating the database of current packages (FreeBSD only):
There is just one more step now- We need to configure FreeBSD to show that we have upgraded Twiki to latest version so that cvsup/portupgrade doesn’t bother us in the future about having an outdated version of twiki.
cd /var/db/pkg
mkdir twiki-20040904

Now, copy 4 files from /var/db/pkg/twiki-20040902 directory to twiki-20040904 directory

# ls /var/db/pkg/twiki-20040904/ 
+COMMENT     +CONTENTS    +DESC        +MTREE_DIRS

In each file, modify the files to resemble information for a 20040904 version

rm -rf twiki-20040902

pkgdb -Fu

portversion -v -l "<" should cease to complain that we have older version of twiki that needs updating.


Comments   FreeBSD
Related posts:

Using fetchmail to download emails from your gmail account

Getting emails from your gmail account into your FreeBSD system requires you to get your hands dirty with SSL and Google’s server certification to communicate via secure POP3 port (995).

Your FreeBSD system should have an usable copy of Google’s certification if you have thawteCb.pem in your /usr/src/crypto/openssl/certs directory.

to index the certification:
===[root] /usr/src/crypto/openssl/certs # /usr/src/crypto/openssl/tools/c_rehash .

to verify the result:
===[root] /usr/src/crypto/openssl/certs # file ddc328ff.0
ddc328ff.0: symbolic link to `thawteCb.pem’

Create your ~/.fetchmailrc to look like the below:
===[root] ~ # cat ~/.fetchmailrc
poll pop.gmail.com with proto POP3
        user ‘xxxxx@gmail.com’ there with password ‘XXXXX’ is ‘xxxx’ here
                options keep ssl sslfingerprint ‘F2:BE:86:E4:E2:51:76:AA:B6:00:91:7B:97:A4:E6:F3′
                        sslcertck sslcertpath /usr/src/crypto/openssl/certs

===[root] ~ # chmod 600 ~/.fetchmailrc

You can test connection to pop.gmail.com:
openssl s_client -connect pop.gmail.com:995 -CApath /usr/src/crypto/openssl/certs

To grab your email from gmail account and have it deposited to one of your local accounts:

fetchmail -d0 -v

Don’t do this more than every 5 minutes (add the ‘-d 300′ on fetchmail command line or ’set daemon 300′ in ~/.fetchmailrc))

The above entry is a shortened version of:
http://download.gna.org/hpr/fetchmail/FAQ/gmail-pop-howto.html   (which contains more details)


Comments   FreeBSD
Related posts:

« Previous Entries