Finding Samba shares mounted by Nautilus

Every now and then I have the need to access a folder shared in a remote computer at home. I normally mount it by hand in the command line using the standard commands:

mount -t cifs -o <username>,<password> //<serveraddress>/<sharename> <mountpoint>
or
smbmount //<serveraddress>/<sharename> <mountpoint>

but this time I wanted to mount it using Nautilus so I entered the URI in the location bar

smb://<serveraddress>

and selected "Mount Volume" from the right-click menu of the share I wanted to access.

It mounted properly but when I wanted to access it from another program I couldn't figure out where the mount was. After some searching I found that Nautilus mounts the Ssamba shares under

~/.gvfs

I have no clue why the Gnome/Nautilus designers decided to hide the mount point when the most obvious reason to mount a share is ti ACCESS it.

To avoid this confusion in the future (I have an awful memory) I decided to create a symlink in my home folder to .gvfs.

Now when I want to mount a remote folder I can find the mount point very easily.

Do you know what was the reason to hide it in the first place?

Inspirational Projects

Over the years that the FLOSS Fund has been running, I have been surprised that people have such a hard time finding projects to nominate. I run into neat projects frequently.

I feel kind of squicky giving you a list (I am NOT suggesting that y'all nominate these projects), but maybe you can use this list to inspire yourself:

  1. FreePOPs, a neat POP3 proxy I used to rescue my e-mail from Yahoo!'s servers.
  2. Cacti, which is a great tool for graphing network activity.
  3. pfSense, which is a pretty nifty firewall project.
  4. TinyMCE, which is one of the two major JavaScript editors that let you do rich-text formatting in text fields. Maybe you're too cool to use it, but lack of WYSIWYG support on the web hobbles many people.
  5. OpenWRT, which has converted many a consumer-grade router into something featureful.
  6. TrueCrypt, which (although not perfect and not DSFG-free) is an excellent cross-platform no-cost encryption tool that even non-technical users can use.
  7. VLC, which makes multimedia tolerable on Free Software platforms.
  8. Imagemagick. Ha ha who uses Imagemagick anymore, right? You might be surprised.
  9. Squid, which is an immensely popular proxy/cache.

These are a few projects which I use and which I find useful (even inspirational). You probably have some too. Even if you don't nominate them for the FLOSS Fund, it is worth thinking about them and appreciating them.

What is kwlug? [Extracted from a proposal.]

What is kwlug?

From the front page of the kwlug web site :

KWLUG - The Kitchener-Waterloo Linux User Group is a monthly meeting of GNU/Linux, Free Software, Open Source and technology enthusiasts. We meet in Kitchener, Ontario, usually on the first (non-holiday) Monday of the month. (Directions) Our meetings are free and open to those with an interest in Linux. Find out more about our meetings. Join our mailing lists.

The Kitchener-Waterloo Linux Users' Group is a group of computer enthusiasts that meet on an ad hoc basis the first non-holiday Monday of every month. Using various flavours of Linux as a base, instead of Microsoft Windows variants, volunteers present on topics that have caught their interest. Although called a Linux user's group, the focus is seldom on Linux itself - instead, the focus is on what people do with computers, be it browse the web, use maps, edit photos, or program - typically, experiences apply whether using Linux, Windows, or any other operating system. The focus is on what we do with computers, not, generally, the nature of the computers themselves. Inevitably, however, the very nature of describing something interesting that was done leads to a technical discussion as to how one goes about doing it.

kwlug is a computer group, it is technical – if you don't mind being dropped in the deep end of the pool, you will thrive.

kwlug is free and open to all to attend, participate, contribute, or just lurk. No expertise or experience is necessary, merely a desire to learn. Come share in the mutual support of like minded people.

It is more accurate to describe kwlug as a free software users' group, not a Linux users' group. All software used is available via free internet download. It would be even more accurate to say kwlug is a FOSS users' group, a particular type of free software - the important point is that not only is there no cost to kwlug, there is no cost to the software. FOSS provides an equal playing field, whether you are a home hobbyist or a large corporation, being barrier free with a very low, and most often no, cost of entrance.

In most every case, there is a free and popular equivalent to most any non-free software application. Skills are almost always transferable, and directly applicable, to proprietary versions.

kwlug is more than just a monthly meeting, it hosts a website at , and two mailing lists. [A mailing list is group e-mail, akin to computer forums or chat groups, but executed via e-mail.]

There is no cost to be part of kwlug, there is no cost to the software used - everyone is able to fully participate and expand their horizons and skills. There is no barrier to entry, and mutual encouragement and help is but an e-mail away.

* 'FOSS', or Free and Open Source Software, is not an intuitive term, but it is an important one. Much like 'conservation' seems intuitively obvious, it quickly becomes quite a complex subject. Excerpting from http://en.wikipedia.org/wiki/Free_and_Open_Source_Software:

Newcomers to the subject can be confused by the term "free". In the context of free and open source software, "free" is intended to refer to the freedom to copy and re-use the software, rather than to the price of the software. The Free Software Foundation, an organization that advocates for free software, suggests that to understand the concept, one should "think of free as in free speech, not as in free beer".

kwlug meetings - location facilities criteria.

The following appears to have been well received by kwlug as an accurate description of what kwlug looks for in meeting location facilities.

Comments for refinement are most welcome - please post them to kwlug-disc.
-----
Wherever we go, we're going to need to manage and meet the expectations of whomever our hosts are, particularly if the space is free - show that we are relevant to the K-W community within which that free space sits.

We also need to know what sort of meeting space we'd like to see.

Some thoughts to seed the discussion:
- cost of entry must be absolutely free.
- reasonably nearby parking of sufficient size must be free.
- on a main bus route.
- big enough, for, say, 40 people, on average.
- chairs; perhaps some tables for those with laptops; projection screen
- QUIET. Working Centre noise is what drove us to look for alternative sites.
- preferable, but we seem to manage if the site doesn't have them to hand: projector, some form of sound system (unless the space is small and quiet enough to not need them.) Best if microphones aren't needed.
- white board? Meeting signs to direct people? One of those giant pads of paper and stand?
- would be nice if larger alternate on-site space were available by pre-arrangement for the better attended topics, e.g. MythTV.
- would be nice if there was space on-site to grab a bite rather than having to go elsewhere. Such would also probably facilitate our 'ask your neighbour' recommendation. Would space, but no restaurant, be acceptable?
- personally I'd prefer to be in K-W, and not the heck the other side of Kitchener.
- Free internet access present. Of some reasonable speed. We have shown that we can largely do without, at the Working Centre, but I don't think people really want to. Enough netbooks are present that I think given two relatively equal choices - one with access, one without, the internet location will be chosen hands down. Even if only for the presenters to be able to show us the web site of whatever they're presenting on.
- not at the Universities - aside from the cost of parking, I think we collide with similar groups already on campus, and they have a slightly different direction than kwlug. (Nothing prevents people from attending both.) kwlug seems focused upon 'downtown everyman', not post-secondary students / academia. No offense to anyone.

There's another aspect that I think we should also discuss. Manulife would have been a fantastic place to meet, probably a really nice setting and environment, but perhaps off-putting to some. On the other hand, the Working Centre, given its raison d'etre, is inherently visible and welcoming to newcomers. Not as stark as a gymnasium but probably not as swank as Manulife. Does the kwlug community have a preference or leaning towards one environment or the other?

Installing WebHuddle

This will be the shortest post from this series.

To install WebHuddle I followed the instructions from the WebHuddle User Guide

There you will find all the steps in detail and a wealth of extra information regarding the WebHuddle configuration.

I did my installation on a minimal Debian install and the instructions worked for me.

kwlug is on BigTent!

The kwlug group on BigTent has now been created.

Think yahoo / google groups on steroids. The only such I've come across that allows subgroups.

It includes forums, news, events, photos, files, calendar, reviews, polls, e-mail (I think) and I don't know what all else.

I've, so far, only created forums for General Discussion, kwlug Discussion, and New Member Help. The only event is the Jan. 4 meeting.

If it's useful, go ahead and start using it. I can create sub-things as demand is identified, create group, file, forum, admins/moderators, whatever, and so on.

(Here is the URL: https://www.bigtent.com/groups/kwlug -Paul)

Comments

Installing OpenMeetings on Debian Lenny

On the previous post I showed you what you could do with OpenMeetings. Now it's time to describe how to install it on your own server.

Although you can install it in any version of Linux provided you have access to the proper dependencies, I decided to do the set up on a minimal installation of Debian 5.03 "Lenny", that way I could ensure I identified all the components needed. This will also ensure that if you want to install it in a different Distribution, you have all the elements to do it.

The total installation time was a bit less than two hours. It may be more or less for you depending on the speed of your computer and Internet connection.

You can find the short version of these instructions on the OpenMeeteings website. Those instructions were my starting point. Here I will add all the detail required.

To start you will need the following

  • A computer to work as the server: Minimum recommended: 1 GHz CPU, 1 GB RAM, 2 GB HDD.
    If you don't have an additional computer you can do the installation on a virtual computer. Just ensure you assign enough CPU, RAM and a large enough HDD.
    From now on I will refer to this computer as the "server"
  • An Internet connection
  • An additional computer connected to the same network. The purpose of the second computer is the following
    - follow the instructions doing cut and paste instead of typing them manually
    - Test the installation at the end
    From now on I will refer to this additional computer as the "local computer"

Install Debian

Although Installing Debian is not in the scope of this post, here is the installation in a nutshell:

  1. Download the minimal network installation
  2. Burn the image to a CD or USB
  3. Boot your computer using the CD or USB
  4. Follow the installation steps
  5. When asked to select the kind of system, just leave "standard system" selected. Nothing more.
  6. When the installation completes, allow it to reboot
  7. Login to the server as root and continue with this instructions.
  8. By default Debian will use DHCP to acquire an IP address. That is OK when you are testing but It is advisable to set a static IP address so your server always has the same IP address. You can follow the instructions here: http://www.techiecorner.com/486/how-to-setup-static-ip-in-debian/

Edit the sources list

This will ensure that you have access to the packages required later in this installation procedure

  1. Edit the sources.list file with your favorite editor. e.g. nano
    nano /etc/apt/sources.list
  2. Add the following two entries at the end of the file:
    deb http://ftp.us.debian.org/debian lenny main contrib non-free
    deb-src http://ftp.us.debian.org/debian lenny main contrib non-free

    Note: you can replace the URL with the one for your preferred mirror
  3. Refresh the apt repositories
    aptitude update

Install SSH on the server and connect to it from the local computer

This step is not required but you will save a lot of time using cut and paste instead of typing all the instructions.

  1. Install the openssh-server. I also install "less" as I use it quite frequently:
    aptitude install openssh-server less
  2. Get the address assigned to the server and write it down.
    Note: On the following instructions I will use 192.168.1.97 as the server address. Please adapt the address accordingly.
    ifconfig
  3. On the local computer open a terminal and SSH to the server as root
    ssh root@192.168.1.97
  4. Now you will have a terminal where to paste the commands that follow in these instructions. You'll be glad that you followed this advice.

Install the required packages and dependencies

This is the step that will take the longest as there are several packages to download and install:

  1. Install swftools version 0.9 or newer. As it is not included in the Debian repositories we will use the Ubuntu install
    wget -c http://mirrors.kernel.org/ubuntu/pool/universe/s/swftools/swftools_0.9.0-0ubuntu1_i386.deb
    dpkg -i swftools_0.9.0-0ubuntu1_i386.deb
    apt-get -f install
    dpkg -i swftools_0.9.0-0ubuntu1_i386.deb
  2. Install the rest of the components from the repositories.
    Note 1: This is a very long line. Type it all in a single command line.
    Note 2: Don't leave unattended. The installation process will ask to provide a password for MySQL and to accept the java distribution license.

    aptitude install unzip mysql-server sun-java6-bin imagemagick ghostscript openoffice.org-headless openoffice.org-base openoffice.org-writer openoffice.org-calc openoffice.org-impress openoffice.org-draw openoffice.org-math openoffice.org-filter-mobiledev openoffice.org-filter-binfilter msttcorefonts pstoedit libpaper-utils ttf-dejavu
  3. Optional: Cleanup the apt-get cache. This will free quite some HDD space.
    aptitude clean
    aptitude autoclean

Install OpenMeetings

We are almost done. It hasn't been too bad, has it?

  1. Get the latest version of OpenMeetings. You can figure out which version you need from the OpenMeetings web site: http://code.google.com/p/openmeetings/downloads/list.
    In this case I used version 1.0
    wget -c http://openmeetings.googlecode.com/files/openmeetings_1_0_r2688.zip
  2. Unzip the downloaded file and move it to the final destination. Although it is OK to put it under whatever folder you prefer, I like puting it under "opt" to be consistent with other software. Also, I name the folder "red5" as the application is actually the red5 server executing the openmeetings application
    unzip openmeetings_1_0_r2688.zip
    mv openmeetings_1_0_r2688 /opt/red5

Configure MySQL

OpenMeetings requires MySQL to use UTF8 by default.

  1. Open the MySQL global configuration file with a text editor
    nano /etc/mysql/my.cnf
  2. Comment out the "bind-address" entry on the file
  3. Search for the [client] section and add the following line
    default-character-set=utf8
  4. Search for the [mysql] section and add the following line
    default-character-set=utf8
  5. Search for the [mysqld] section and add the following lines
    default-character-set = utf8
    skip-character-set-client-handshake
    collation-server = utf8_unicode_ci
    init-connect='SET NAMES utf8'
    character-set-server = utf8
  6. Exit saving the file: [ctrl-x] and accept saving the file
  7. Restart mysql
    /etc/init.d/mysql restart
  8. Login to MySQL and confirm the character set
    mysql -p
    (enter the mysql root password)
    show variables like '%char%';
    exit

    All the entries should reflect the use of utf8

Configure OpenMeetings

OpenMeetings can use a variety of database engines. In this installation we are using MySQL so we'll use the predefined MySQL configuration:

  1. Copy the OpenMeetings mysql configuration to the default configuration file
    cd /opt/red5/webapps/openmeetings/conf
    cp mysql_hibernate.cfg.xml hibernate.cfg.xml
  2. Open the default configuration file with a text editor
    nano hibernate.cfg.xml
  3. Enter the mysql root password on the connection.password property
    Note: It is advisable to use an ID different than root to connect but configuring it is outside the scope of these instructions. If you use an ID different than root, please adapt this instruction accordingly
    <property name=”connection.password”>openmeetings</property>
  4. Exit saving the file: [ctrl-x] and accept saving the file

Test the installation

  1. Start openoffice headless
  2. Start red5
    cd /opt/red5
    sh ./red5.sh
  3. Open a browser on the local computer and point it to the following address:
    http://localhost:5080/openmeetings/install
  4. Follow the instructions on that page.
    Once you accept the configuration it may take a long time (about 10 minutes) to complete, so be patient. It is normal.
  5. At the end of the process you will be able to open your first web conference!!!

You are done!... Well, almost.

Set up the startup scripts

Although you can manually start red5 every time, I am sure you'd prefer for it to start as a daemon every time you start the server.
I've created the startup scripts followig the standard Debian init.d conventions. You can find the scripts attached to this post.

  1. Download the file openmeetings-startup.tgz to the local computer
  2. Untar the startup scripts and upload them from the local computer to the openmeetings computer.
    Note: For this you will need to open an additional terminal on the local computer
    tar -xvzf openmeetings-startup.tgz
    scp -P 22 red5 root@192.168.1.102:/etc/init.d/red5
    scp -P 22 soffice-headless root@192.168.1.97:/etc/init.d/soffice-headless
    scp -P 22 soffice-headless.sh root@192.168.1.97:/usr/lib/openoffice/program/soffice-headless.sh
  3. On the server terminal make the scripts executable
    chmod 755 /opt/red5/red5.sh \
    /etc/init.d/red5 \
    /etc/init.d/soffice-headless \
    /usr/lib/openoffice/program/soffice-headless.sh
  4. Add the scripts to the startup sequence
    update-rc.d red5 defaults
    update-rc.d soffice-headless defaults
  5. Restart the computer.

Opening the ports
If you want to allow people external to your network to connect to OpenMeetings, you will need to open the following ports:
5080, 8100, 1935 and 4445.

If you prefer to use different ports, you will need to modify the red5 and OpenMeetings configuration files, but that's outside the scope of this post.

Now you are really done!!

As you can see, setting up the server is not too difficult. Nothing to compile and very little to configure. Have fun using this tool.

File Attachments

Attachment Size
openmeetings-startup.tgz 1.1 KB

Web conferencing

All the tools and methods described on the previous posts work very well with a small number of people sharing a desktop or collaborating, given that access must be granted and computer addresses shared, they work well within a trusted group.

For situations where you need to collaborate with "untrusted" people or with a large number of people, the best option is to use web conferencing software.

As the slide indicates there are many on line providers where you can subscribe either for free or small monthly fee and you can start hosting conferences on their servers. There are a few with Linux Clients, some "even" allow to share the Linux desktop.

Here are some examples of hosted services:

  • DimDim: Free/Paid, no Linux desktop Sharing, FLOSS version
  • Elluminate: Free trial/Paid, Full platform support, hosted
  • Yugma: Free/Paid, Full Linux support, hosted
  • Follow this link for a miniguide to web conferencing tools

The market is moving so fast that I'm expecting that this list will grow and change quite rapidly in the next few years.

For the KWLUG presentation I decided to focus on two Free Software applications, OpenMeetings and WebHuddle, which can be hosted on your own servers, branded, and otherwise modified.

OpenMeetings:

  • UI implemented in OpenLaszlo compiled to Adobe Flash
  • Desktop sharing implemented in Java
  • Document sharing, white board, Desktop Sharing, Audio/Video conferencing
  • Ideal for intranet conferencing
  • Runs under Red5 (Flash media server)

Pros:

  • Nice interface
  • Skinable
  • Actively developed
  • Administrator manages rooms and user permissions the rooms. Specific users have access to specific rooms
  • Two different types of rooms: Audience (Moderated), Conference (non-moderated)
  • Very light on the server side
  • No viewer installation required (Installation required to share the desktop or to use the Flash viewer)
  • Allows sharing MS Office and OpenOffice documents
  • Documents can be uploaded by any presenter while in a meeting
  • Supports LDAP authentication.

Cons:

  • Users must have a Flash and Java enabled browser
  • Resource intensive and slow on the client side due to the Flash implementation
  • All users must register. (you can create a "generic" id but any person using it may change the generic ID profile, including the password)
  • No remote control

WebHuddle

  • Implemented in Java
  • Document sharing, white board, Desktop Sharing, Audio conferencing
  • Ideal for intranet/extranet conferencing
  • Not under active development but it is not a dead project. It's a solid finished product. The original developer still answers questions in the forum.
  • Runs under Jboss (Flash media server)

Pros:

  • Simple interface
  • Non-registered users can join meetings. Users must know the host's email and the meeting's password
  • Very light on the client side
  • Very light on the server side
  • Allows sharing a screen region instead of the whole screen
  • Offers meeting recording functionality
  • Supports LDAP authentication.

Cons:

  • Users must have a Java enabled browser
  • No functionality to recover a forgotten password. (although there is a workaround)
  • No video sharing
  • Only allows ppt, sxi (old open office) and gif/jpeg files
  • Shared documents can only be uploaded by the meeting owner before the meeting starts
  • No remote control.

Summary
Web conferencing is an excellent collaboration technique for distributed groups as well as a great medium for presentations to remotely dispersed audiences.

Whether you set up the server yourself or you use a vendor hosted solution, you can be sure that there are options for Linux, try them, you have nothing to loose and a whole lot to gain.

On the next two posts I will show you how to install the two servers described in this post.

File Attachments

Attachment Size
webconferencing.jpg 43.64 KB
openmeetings.jpg 37.04 KB
webhuddle.jpg 32.63 KB

NX

On my post about XDMCP I mentioned that there was a better way to open a X session on a remote computer.

After reading this post you'll see why I left it at the end of this blog therad: NX uses elements and concepts explained on the previous posts (SSH, X forwarding, XDMCP, VNC)

Nomachine, creators of the NX protocol, have a closed source implementation of the protocol, with free (no-cost) versions for both the client, server and nodes and also paid support plans.

They've open sourced the compression algorithm and protocol and provided very detailed documentation.

The open source implementation is FreeNX

Although the server must run on an Linux/Solaris/BSD system and natively provides support for the X protocol, the server can also work as a gateway to access RDP (Windows Terminal server) or VNC connections to other Operating systems.

The client can work on Linux, Windows, Mac

It can start a full session similar to XDMCP or a single application, similar to SSH X forwarding.

The implementations work over SSH

Here is a diagram of NX in a nutshell.

Installing it
To use NX you must install the server on the remote computer and the client on the local computer.

Note: The server must have a properly configured SSH server. The client must be able to SSH to the server. i.e. the port must be open and security properly set up.

The installation for the non-open source version is clearly explained on the Nomachine website

But it is basically Download and execute the installers.

To set up the open source version search for instructions for your distribution. For example:

Debian/Ubuntu
https://help.ubuntu.com/community/FreeNX

Fedora
http://www.blogcatalog.com/blog/kernelhardware/460cb0944dffe0636484b73327ed9f12

Connecting
Once the server has been set up, and the client installed, creating a new session is quite easy. Just start the client, and define the server address, desktop environment and geometry.

Here is a snapshot of QtNX, Although comparative to the no-machine closed source version this client provides less functionality, it is still quite usable.

RDP and VNC
To connect to a Windows server through Remote desktop or to any OS through VNC, you must have a Linux server on the same side of the network as the server you want to access.

If you are connecting to Remote desktop, the Linux server must have rdesktop installed
If you are connecting to a VNC server, the Linux server must have tight VNC installed

The client connects to the Linux server which in turn uses rdesktop or the VNC viewer to connect to the destination server. (See diagram above)

This means that when configuring the session you must define both the Linux server address and the address of the destination server as seen by the Linux server.

For more detailed information

The Nomachine website is full of information on both the closed source and the open source implementation
http://www.nomachine.com

The FreeNX website has information on the open source implementation
http://freenx.berlios.de/

File Attachments

Attachment Size
nx.jpg 35.04 KB
nx-protocol.jpg 42.56 KB
QtNX_Settings.png 43.12 KB
nx-rdp.png 52.16 KB

VNC (Virtual Network Computing )

Up to now the graphical solutions I've shown were focused on accessing the X desktop. I've also focused on accessing a session exclusively.

On this post I will talk about a tool that is OS independent. You can share a Mac or Windows or Linux desktop and that allows remote collaboration with multiple people looking and controlling the same desktop.

VNC uses the RFB protocol to transmit keyboard and mouse signals to remote computer and receive back the graphical screen.

Most implementations under Linux allow sharing a secondary session but a few allow sharing the main desktop.

My preferred one which is distribution and desktop manager independent is x11vnc

Connecting through VNC

On the server side:
x11vnc -display :0

On the client side
vncviewer hostaddress:0

Of course you can open additional sessions. This is useful when you want to have multiple people working on the same computer on different sessions.
x11vnc -display :1

Sometimes (usually due to port blocking) you need to have the client waiting for the server to open the connection.

To do the reverse VNC the local computer “listens” and the remote computer connects
On the local computer
vncviewer -listen

On the remote computer
x11vnc -connect home-desktop

Configuration
When connecting to the main desktop there is no additional configuration. But when connecting to an additional session you must specify what kind of session it is.

You do this by modifying the ~/.vnc/xstartup script.

Tunneling VNC over SSH
The VNC protocol opens by default port 5900.

VNC is not an inherently safe protocol so when connecting to a computer using VNC over the open Internet it is advisable to do it over an SSH tunnel

SSH to the remote computer opening the VNC listening port

ssh user@remotecomputer.com -L 5900:localhost:5900

Once connected execute the command on the remote console
sudo x11vnc -display :0

On the local computer open a different console

vncviewer localhost:0

Gnome
Gnome includes a set of VNC server and client that allow sharing the main desktop

The server is called Vino and is located on the main menu under Preferences | Remote desktop

There you can enable it and set other connection parameters

The client is called Vinagre and is located under Internet | Remote desktop viewer

KDE
KDE also includes a set of VNC server and client

The server is called kfrb and is located on the main menu under Internet | Desktop Sharing

The client is called krdc and is located on the main menu under Internet | Remote Desktop Client

The KDE client has some nicer features such as scaling and full screen "on the fly"

File Attachments

Attachment Size
vnc.jpg 53.49 KB
vino.png 44.36 KB

XDMCP

XDMCP stands for X Display manager control protocol.

The display system used in Linux was designed from the beginning as a network protocol, where the system and programs run in one computer and the display being shown on another.

The XDMCP protocol allows you to login graphically to a remote computer.

It is not a very fast protocol and these days there are better ways to achieve the same effect in a more efficient manner.

As of Gnome 2.2 and KDE 4 support for XDMCP login on the GDM/KDM login screen was dropped.

It is still possible to configure and setup XDMCP under those environments but it was easier when the distributions set it up from the get-go.

Gnome

If you are using a version earlier than Gnome 2.2:
On the computer you want to log in to. XDMCP must be enabled:
1. From the main menu open
"Administration | Login Window"
2. On the "Remote" tab select a style

On the local computer
1. On the Login manager select "Session"
2. On the session Menu select "Secure remote connection"
3. Select the server you want to connect to and login.

If you are using Gnome 2.2 or newer you need to do it all by hand

On the computer you want to log in to. XDMCP must be enabled:
1. modify /etc/gdm/gdm.conf-custom to enable xdmcp

[xdmcp]
Enable=true

Reboot computer

On the local computer:
There are several ways, xinit, Xephyr, xnest, and others

For example
sudo xinit -- :2 -query 192.168.1.103

or
Xephyr -query 192.168.1.103 :1 -host-cursor -screen 800x600

KDE
For KDE

Here it is explained quite nice

For more detailed information
http://tldp.org/HOWTO/XDMCP-HOWTO/index.html

File Attachments

Attachment Size
loginpreferences.png 47.28 KB
sessions.png 243.22 KB

Putty

For different reasons, some people prefer Graphical interfaces, whether it is because because they are more comfortable with them or because they may set-up a non technical person for remote access.

On the past two posts I presented command line tools. These tools require, for the most part, remember cryptic parameters, configuration file locations and unless you script them, you need to enter the whole command every time even if you are doing the same day after day.

The solution: Putty

Being this a GUI tool It requires less words to explain.

Installing it
Using your distribution package manager search for it and install it. I still haven't found a distribution that does not include it.

Configuring a connection

1. Enter the Host name or address
2. Enter the port number the host is listening to
3. Select the protocol
4. Name the connection
5. Click "Save"

Once the connection has been created you can do additional configuration.

There are many different configuration categories.

Terminal: This is a functional configuration. How do you want the terminal to behave

Window: This is aesthetic. How do you want the terminal to look.

Connection: Protocol specific configuration.

For SSH, for example, you can configure almost everything that you can do from the command line and configuration files.

You can enable X11 forwarding and open tunnels, including reverse tunnels.

Here is an example where the VNC tunnel is already configured and I am about to add tunneling port 50022

Saving the configuration
Once you complete configuring your session, you must go back to the main session configuration page and click "Save".

Note: If you click "Open" before saving, you will connect with everything you just configured but the configuration will be lost as soon as you close the session.

Using a saved configuration
The next time you open putty you will see the list of saved configurations.

Just select the configuration you want to use and click "Load"

You can then modify the configuration, re-save it or simply click "Open" to connect to the remote computer.

Note: The first time you connect you will be prompted to accept the host key.

Creating a "launcher"
If you want to launch a preconfigured connection by just clicking in an Icon you can create a launcher

On graphical environments such as KDE or Gnome you can create icons that launch an application.

The trick here is to use the -load parameter followed by the name of the saved connection.

For example, under Gnome:

For more detailed information

You can go to the main putty page:
http://www.chiark.greenend.org.uk/~sgtatham/putty/
You can find more

File Attachments

Attachment Size
putty.jpg 23.77 KB
putty1.png 14.45 KB
putty2.png 14.22 KB
putty3.png 19.79 KB

SSH

The second command in the series is the one I find more useful and versatile so it also will be the longest post.

Different implementations of SSH will have slightly different features. In this case I will focus on OpenSSH.

To install on the server (Debian/Ubuntu):
sudo aptitude install openssh-server

To install on the server (Redhat/Fedora):
sudo yum install openssh-server

To start/stop/restart under Debian/Ubuntu
sudo /etc/init.d/ssh start
sudo /etc/init.d/ssh stop
sudo /etc/init.d/ssh restart

To start/stop under RedHat/Fedora
service sshd start
service sshd stop
service sshd restart

confirming that the port is open
To check that the port is open by name
netstat -l | grep -i ssh

Or faster and more specific, to check by port number
netstat -ln | grep 22

Note: if you configure SSH to listen to a different port as explained later in this post, replace 22 with the port configured.

Once the server is running you can connect from other computers as long as the port is not blocked by a firewall.

Command examples

SSH has many parameters. They are described on the man pages
man ssh

Here are some basic (and very common) examples:

The basic command to connect to a server (host) assumes that ssh is listening to port 22 and that you want to connect with the same userID as you are using on the local computer. Host name is the only mandatory parameter:

ssh 192.168.1.100
or
ssh mycomputer.com

Connecting using a userID "rarsa" on the remote computer
ssh rarsa@mycomputer.com
or
ssh mycomputer.com -l rarsa

When the server is listening to a different port
ssh -p 50022 rarsa@mycomputer.com

Using SSH to copy files
Sometimes you will need to copy a file (or folder) from your local computer to a computer where you have SSH access. SSH provides a command that allows you to do a secure copy "scp"

The main parameters are:
- The file name for the file you want to transfer
- The address of the remote computer, and user id if you are using a different one
- The destination path and name

scp "source" "destination"

Source and destination can be fully qualified indicating the userID, server name, destination path

scp file rarsa@192.168.1.102:/destinationPath/file

You can copy directories recursively and between other hosts and use different ports

scp -P 50022 -r rarsa@192.168.1.101:/sourcePath/directory rarsa@192.168.1.102:/destinationPath/directory

X forwarding
OK, accessing the remote computer and executing commands is handy and exciting and maybe all you need to do, but what if you want to run a graphical application on the remote computer?

ssh has the -X parameter that allows the GUI of the remote program to display on your local computer

First ssh to the remote computer
ssh rarsa@mycomputer.com -X

Then on that console, execute the program. e.g. to run Firefox:
firefox

The program will be actually running on the remote computer but the Graphical interface will show in the local computer!

Note: When using X forwarding this way, we refer to the program running on the remote computer as "the client" and to the local computer displaying the GUI as "the server".

Port forwarding/tunneling
One of the most powerful features of SSH is the ability to "forward ports" sometimes referred as "tunneling"

Port forwarding allows forwarding of TCP/IP connections to a remote machine over an encrypted channel.

This is, imagine that you need to FTP (port 21) to a remote computer which is behind a firewall that only allows SSH connections.
ssh rarsa@remotecomputer.com -L50021:localhost:21

This command will "tunnel" the FTP traffic from port 50021 on the local computer to port 21 on the remote computer

Now you can ftp to the remote computer with the following command
ftp localhost 50021

Note, you can specify any available port you want on the local computer, but you must specify the correct port listening on the remote computer

Reverse tunneling
If you want the remote computer to access a port on yours but you are behind a firewall that closes all incoming ports, you do "reverse tunneling"

You first connect to the remote computer specifying that the a port on the remote computer will be forwarded to a port in your computer. For example, for FTP:
ssh rarsa@remotecomputer.com -R50021:localhost:21

Now the remote computer can FTP to your computer using port 50021.

Note: you can specify any available port you want on the remote computer, but you must specify the correct port listening on the local computer).

Combining it all
You can tunnel (and reverse tunnel) various ports on the same ssh command.
You can even indicate that the remote computer should forward to a different server!

For example, to allow your computer to FTP to the remote computer and at the same time allow the remote computer to SSH to your computer and at the same time forwarding port 80 to the web server in the same network
ssh rarsa@remotecomputer.com -L50021:localhost:21 -R50022:localhost:22 -L8080:webserver.com:80

I personally use reverse tunneling to SSH to my father's computer which is behind a firewall. He just needs to execute the ssh command to connect to my computer opening a reverse tunnel for port 22, I can then SSH back to his computer using the reverse tunnel.

On my father's side (assuming he has a "dad" id on my computer):
ssh dad@mycomputer.com -R50022:localhost:22

On my computer (assuming I have a "rarsa" id on his computer:
ssh rarsa@localhost

Configuration
The ssh client takes it's parameters, in order of precedence from:
1. Command line parameters
2. User configuration file ~/.ssh/config
3. System-wide configuration file /etc/ssh/ssh_config

The sshd server daemon takes it's parameters, in order of precedence from:
1. Command line parameters
2. System-wide configuration file /etc/ssh/sshd_config

Server configuration file
/etc/ssh/sshd_config

Note: you must restart the SSH daemon after modifying the configuration file

For example, to prevent portscans use a different port by editing sshd_config and specifying the port.
port 50022

You can look at all the options on the man pages
man sshd_config

Client configuration file
As we've seen before, the SSH command can get quite long. If you normally use the same parameters in general or particular parameters for a remote server, you can configure all that on your local SSH configuration file
~/.ssh/config

For more detailed information:

The man pages:
man ssh
man sshd
man ssh_config
man sshd_config

The OpenSSH website:
http://www.openssh.org/

The web:
There are some very good examples of port forwarding, just search for them.
For example
http://souptonuts.sourceforge.net/sshtips.htm

File Attachments

Attachment Size
ssh.jpg 44.2 KB

Comments

There are Windows equivalents - useful as clients for these servers, or as servers for these clients.

Typically, there are two ways to go about this - standalone, or as part of Cygwin.
(http://www.openssh.org/windows.html)

For standalone: http://sshwindows.sourceforge.net/
(At least I think that's where I got mine from.)

As part of a larger cygwin installation (LOTS of goodies here, well beyond just ssh): http://cygwin.com/
- after installation, particularly of the ssh server package, everything is almost exactly the same as described in the blog post. Probably the hardest part is getting used to the file structure / configuration file locations.
- http://cygwin.com/packages/
- substantially, these are Linux equivalent command line facilities. Graphics, X, KDE, etc., are out there, but not as solid as base / command line cygwin itself.

There are lots of Windows VNC servers/clients out there:
- my favourite: TightVNC - http://www.tightvnc.com/
- very popular: http://www.realvnc.com/
- also very popular: http://www.uvnc.com/

Telnet

I'll start this series with the simplest and oldest command.

Remember, it is not safe to expose telnet to the internet.

To install on the server (Debian/Ubuntu)
sudo aptitude install telnetd

To start/stop under Debian
Under Debian, the telnet daemon is started by inetd when the port is accessed. This is controlled by the inetd.conf file. If the telnet line is commented out, telnet will not start, otherwise it will start.

After modifying the inetd.conf file you must restart inetd for the changes to take effect.

Comment or uncomment the telnet line
sudo nano /etc/inetd.conf

Restart inetd
sudo /etc/init.d/openbsd-inetd restart

To start/stop under RedHat

chkconfig telnet on
chkconfig telnet off

confirming that the port is open
To check that the port is open by name
netstat -l | grep -i ftp

Or faster and more specific, to check by port number
netstat -ln | grep 23

Connecting from the client
Once the server has started, you can connect from the client
telnet [server address]

For example:
telnet 192.168.1.105

Ending the session
To close the session
exit

File Attachments

Attachment Size
telnet.jpg 41.5 KB

kwlug logo, with text, posted.

 

Was looking for a kwlug logo but didn't find any with text - so cut out the logo and words from mud.jpg (from the tar download available on the resources page: /node/404 ). Here is the result(s).

 

K-W Lug Logo (with words) - /sites/kwlug.org/files/2009-12-15 kwlug logo (with words).jpg

 

K-W Logo (with words) [sized x2] - /sites/kwlug.org/files/2009-12-15 kwlug logo (with words) x2.jpg

 

File Attachments

Introduction to remote collaboration tutorials

Phew! It's been a week since the KWLUG meeting where I talked about remote collaboration.

Believe or not, I hadn't had a moment, until now, to make good on my promise to post the tutorials on-line.

First I was on Project Management training in Toronto from Monday to Wednesday, then, Thursday and Friday preparing for an implementation at work that kept me at home in front of the computer all Saturday and Sunday.

How is this relevant to the collaboration topic? Well, For this implementation we had people at several locations in Halifax, Toronto, KW and Argentina. Most people working from home. Most of the work done remotely on the servers.

To coordinate the work, I recommended the main project manager to share the task by task schedule through an webconference while we were on a phone conference. We had some hiccups that required modifying the schedule on the fly. Everybody was able to see the changes and agree with them with little discussion and even less confusion.

While I was on a 2 hour break during a long running task I received a call from a different team doing a different, unrelated release. To understand the problem I opened another webconference to allow the developer share her desktop and explain it visually. Once I saw the problem I was able to provide a solution in a couple of minutes. Trying to explain the problem over email or even on the phone would have taken substantially longer.

Ultimately, even though I was working all weekend, I was able to do it in my pajamas in the warmth of my home and I didn't miss a beat.

The rest of the week I will post one topic per day, including a bit more detailed instructions that I didn't have time to present.

I hope you enjoy and contribute with even better ways to do what I'm doing.

Remote Collaboration: A successful presentation

It seems that the time was well spent preparing this presentation. I had an awesome and engaged audience that kept with me through out the presentation, even while we were trying to sort the technical limitations of the physical space.

Unfortunately it seems that the webcast wasn't as successful due to the limited bandwidth at the meeting location. Next time I'll use plan B.

If you logged in remotely, please let me know how was your experience. was the sound good? was the screen choppy? What would you like to see for next time?

I guess the same questions go to the people that were at the presentation. I you have suggestions on how the presentation could've been better, please let me know even through the list or to my email if you prefer direct communication. I'd really appreciate the feedback.

As promised, I've uploaded the presentation slides to the meeting invitation.

In future posts I will write down the tutorials for the tools I used. I'm right now too tired and going to bed.

Thank you to all the people that came to the presentation, that is really what makes it worthwhile.

GNU Screen Slides (Karmic Party)

I will never admit to going to a Linux launch party. No siree. But if I had gone to a hackerspace party and been coerced into presenting something, I might have made some slides like these.

The zip file contains slide sources and configuration snippets. I am puttting them here because I don't want to make an account on the Kwartzlab wiki.

File Attachments

Attachment Size
2009-10-29-screen.zip 15.06 KB
2009-10-29-screen.pdf 68.65 KB