Showing posts with label ubuntu. Show all posts
Showing posts with label ubuntu. Show all posts

Saturday, September 26, 2015

Linux - PPTP VPN Server (via GUI on Ubuntu)

 

How to Setup a “Split Tunnel” VPN (PPTP) Client on Ubuntu 10.04

Sometimes you need to use a VPN connection to grant access to remote network resources and for that you use a VPN, but if you don’t want all of your client traffic to go through the VPN link, you’ll need to setup your VPN to connect in a “split tunnel” mode. Here’s how to do it on Ubuntu.

Note: make sure that you’ve read our article covering how to setup a VPN server for Debian-based Linux, which also covers configuring the Windows client.

 

Split what the what now?

The “split tunnel” term refers to the fact that the VPN client creates a “tunnel” from the client all the way to the server for “private” communication.

Traditionally the VPN connection is set up to create “the tunnel” and once it is up all the client’s communication is routed through that “tunnel”. this was good back in the day when the VPN connection had a couple of goals that overlapped and complimented each other:

  • The connection was meant to grant access for the road warrior from anywhere.
  • All of  the client’s connections need to be secured by means of  going through the corporate firewall.
  • The client computer must not be able to connect a potentially malicious network with the corporate network.

The way the VPN connection of the time achieved this goal, was to set the “default gateway” or “route” of the client machine to the corporate VPN server.

  • This method, while affective for the above goals has several disadvantages, espeshelly if you are implementing the VPN connection only for the “grant access” point:
  • It will slow down the entire surfing experience of the client computer to the speed of the VPN server’s upload speed, which is usually slow.
  • It will disable access to local resources like other computers in the local network unless they are all connected to the VPN, and even then the access will be slowed down because it has to go all the way to the internet and come back.

To overcome these shortcomings we will create a regular VPN dialer with one note worthy exception, that we will set the system to NOT use it as the “Default Gateway” or “route” when connected.

Doing this will make it so that the client will use the “VPN tunnel” only for the resources behind the VPN server and will access the internet normally for everything else.

 

Let’s get cracking

The first step is to get into “Network connections” and then “Configure VPN”.

One way you can do this is by clicking the desktop icon for networking as shown in the picture.

clip_image001

Another way is to go to “System” > “Preferences” > “Network Connections”.

clip_image002

Once your on the “VPN” tab in the “Network connections” configurations window, click “Add”.

clip_image003

On the next window we only need to click “Create”, as the default connection type of PPTP is what we want to use.

clip_image004

In the next window give your dialer a name, fill in the gateway with your servers DNS-name or IP address as seen from the internet and fill in the user credentials.

If you have used the “Setting up a VPN (PPTP) server on Debian” guide for the server setup or you are using this client for a DD-WRT PPTP server setup, you also need to enable the MPPE encryption options for authentication.

Click on “Advanced”.

clip_image005

On the “Advanced Options” window check the first checkbox for the MPPE option, then the second checkbox to allow stateful encryption and click “OK”.

clip_image006

Back on the main window, click the “IPv4 Settings” tab.

clip_image007

On the routes configuration window check the checkbox of “Use this connection only for resources on its network”.

clip_image008

Activate the VPN connection client by clicking on the “Network connections” icon and selecting it.

clip_image009

That’s it, you can now access the resources on the VPN servers side as if you were on the same network while not sacrificing your download speed in the process…

 

Taken From: http://www.howtogeek.com/51340/setting-up-a-split-tunnel-vpn-pptp-client-on-ubuntu-10-04/

Monday, November 24, 2014

Change MAC Address on Linux (Ubuntu / Debian)

Temporary MAC Address Change

When you change the MAC address for an interface, you need to have the network interface disabled (down) and than to set the new MAC.

You can do both this things with the command:

$ sudo ifconfig eth0 down hw ether AA:BB:CC:DD:EE:FF && ifconfig eth0 up

This sets down the eth0 interface, changes the mac to AA:BB:CC:DD:EE:FF and turns the interface back down.

Or, do it in the old fashioned way:

$ sudo ifconfig eth0 down
$ sudo ifconfig eth0 hw ether AA:BB:CC:DD:EE:FF
$ sudo ifconfig eth0 up

Read more about the ifconfig command here.

 

Permanent MAC Address Change

To set the hardware address (MAC), open the /etc/network/interface file in your favourite text editor:

$ sudo vim /etc/network/interfaces

After the network interface configuration, paste this line: hwaddress ether AA:BB:CC:11:22:33.
Note: AA:BB:CC:11:22:33 is just a sample, replace it with the MAC address you want to set for your interface.

Example, with dhcp enabled network interface:

auto eth0
iface eth0 inet dhcp
hwaddress ether AA:BB:CC:11:22:33

Example, with a network interface having a static ip:

auto eth0
iface eth0 inet static
address 192.168.0.100
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
gateway 192.168.0.1
hwaddress ether AA:BB:CC:11:22:33

To apply the MAC change, restart the network interface:

$ sudo /etc/init.d/networking restart

Based On:

Saturday, July 27, 2013

Ubuntu – Packages for Old Releases

The repositories for older releases that are not supported (like 9.04, 9.10, and 10.10) get moved to an archive server. There are repositories available at http://old-releases.ubuntu.com

The reason for this is that it is now out of support and no longer receiving updates and security patches.

I would urge you to consider a supported distribution. If your computer is too old in terms of memory or processor then you should consider a distribution such as Lubuntu or Xubuntu.

If you want to continue using an outdated release then edit /etc/apt/sources.list and change archive.ubuntu.com to old-releases.ubuntu.com

then update with

sudo apt-get update && sudo apt-get dist-upgrade

See also:

· https://help.ubuntu.com/community/EOLUpgrades/

Taken From: http://askubuntu.com/questions/91815/how-to-install-software-or-upgrade-from-old-unsupported-release

Saturday, December 15, 2012

Android Emulator on Linux (Ubuntu)

When Google announced and released Android, back in October 2008, everyone knew that it would become the best operating system for mobile devices. Not only is Android open source, but it also comes with a Software Development Kit, which offers the necessary APIs and utilities for developers to easily build powerful applications for Android-powered mobile devices. The following tutorial was created especially for those of you who want to test the Android platform and install various applications, on the popular Ubuntu operating system. OK, so let's get started... shall we?


Grab the Android SDK from Softpedia and save the file on your home folder.

Editor's note: The tutorial was rewritten for the new Android 2.0 or later, which provides a graphical user interface to setup a virtual device and the SD card. This makes everything a lot easier. No more command-line madness!
Step 1- Installing the requirements
Until the download is over, make sure that you have Java installed and the 32-bit libraries (for the x86_64 users ONLY). If you don't have Java (or the 32-bit libraries), go to System -> Administration -> Synaptic Package Manager...

clip_image002

...search for openjdk and double-click on the openjdk-6-jre entry...

clip_image004

...then, search for ia32-libs (ONLY if you are on a x86_64 machine), and double-click on the ia32-libs entry...

clip_image006

Now, click the "Apply" button to install the packages. Wait for the packages to be installed and close Synaptic when the process is finished.
Step 2 - Android Setup
When the Android SDK download is over, right-click on the file and choose the "Extract Here..." option...

clip_image008

Enter the extracted folder, then enter the tools folder and double click the android file. Click on the "Run" button when you will be asked what you want to do, and the Android SDK and AVD Manager interface will appear...

clip_image010

Go to the "Settings" section and make sure you check the "Force https://..." box. Click the "Save & Apply" button....

clip_image012

Now go to the "Installed Packages" section and click the "Update All" button. A window will appear with all the available updates. Click the "Install Accepted" button...

clip_image014

...and wait for the packages to be downloaded and installed. It will take a while if you have a slow bandwidth, so go see a movie or something until it finishes...

clip_image016

Close the update window when it's done and you will see all the installed SDKs in the "Installed Packages" section.
And now, let's create the virtual device. Go to the "Virtual Device" section and click the "New" button. In the new window do the following:
- put a name to the device;
- select a target (Android system);
- put the size for the SD Card;
- add the hardware you want have in the emulator.
It should look something like this...

clip_image018

Click the "Create AVD" button when you're done setting up the virtual device and wait for it to finish. It takes about 1 minute, and you'll be notified by a pop-up...

clip_image020

Note: In the above setup, we've created a virtual device for Android 2.0.1 with a 2 GB SD card and the following hardware components: SD Card, GPS, Accelerometer, Track-ball and touch-screen.
Now click the "Start" button, and the "Launch" button from the next dialog, and the emulator will start...

clip_image022

clip_image024

To make things a lot simpler let's create a desktop shortcut, so you won't have to open the terminal every time and type some command, in order to start the Android emulator. Therefore, right-click on your desktop and choose the "Create Launcher..." option...

clip_image026

In the Create Launcher window, type "Android Emulator" (without quotes) in the Name field, and paste the below line in the Command field. Optionally, you can also put a nice icon if you click the icon button on the left...
/home/YOURUSERNAME/android-sdk-linux_86/tools/emulator @softpedia

clip_image028

Note: Please replace YOURUSERNAME and the name of the Android Virtual Device (softpedia in our case) with your USERNAME and the name you gave to the virtual device. DO NOT REMOVE the @ sign.
Step 3 - Run applications in Android
All you have to do now is double-click that desktop shortcut you've just created. The Android emulator will start. Wait for the operating system to load...

clip_image030

When the Android operating system has loaded, you can install and test applications. If you are used with the Android platform, you already know how to do that, but if this is your first time... follow the next instructions.

clip_image032

Android 1.1

clip_image034

Android 1.5

Click the Browser icon, wait for the browser to load and click Menu -> Go to URL. Enter the address from where you can download an Android application with the apk extension. For example, we've easily installed Android's Fortune from Launchpad...

clip_image036

clip_image038

clip_image040

clip_image042

clip_image044

clip_image046

clip_image048

...all you have to do is follow the on-screen instructions!
Have fun, and do not hesitate to comment if you want to know more about Android, or if you're stuck somewhere in the tutorial.

Taken From: http://news.softpedia.com/news/How-to-Run-Android-Applications-on-Ubuntu-115152.shtml

Wednesday, September 5, 2012

Linux Desktop On Your Android Phone (Ubuntu)

Of all the various flavors of Linux available to those looking for an open-source platform from which to compute, Ubuntu is by far the simplest to install – allowing even the most hapless noob to download and enjoy.

Being that Google’s Android is also open source, developers have enjoyed a great deal of success porting Windows 95, 98, XP, as well as many other Linux iterations onto Android devices, but hitherto, not Ubuntu.

Those of you running a rooted Android may be pleased to learn of Ubuntu Installer, a Market app which - yes, you’ve guessed it - installs Ubuntu. Even for the unseasoned tinkerer, it’s pretty simple to install – providing you check for the compatibility of your device/ ROM in advance.

clip_image001

Here is a list of the key features:

  • Run Ubuntu within Android.
  • Access to both Android & Ubuntu at same time.
  • Highly optimized for ARM devices.
  • LXDE Desktop (very lightweight)
  • Ubuntu update manager, Software centre fully operational.
  • File system access: Ability to access files on your SD card and internal memory from Ubuntu.
  • Set resolution: Ability to set screen size on boot (you no longer have to download a certain image for different screen sizes!)
  • Choose Ubuntu Installation type: ‘large’ and ‘lightweight’

By default, we always recommend performing such installs on spare devices as opposed to your daily runner. We don’t expect anything to go wrong, but if it were to, we wouldn’t want the issue to intervene with your daily digital errands.

clip_image002

There’s a large version of the installer (1.5 GB downloaded, 3.5 GB installed), which comes with all the bells and whistles such as Firefox, Thunderbird, openoffice.org suite, GIMP Image Editor and so forth, as well as a lightweight version, which contains the basic features required for Ubuntu to function without a hitch.

clip_image003

clip_image004

Before you download, please check the compatibility of your device via the developer’s blog.

Download Ubuntu Installer for Android [Market Link]

Please let us know how you get on with Ubuntu Installer; feel free to share your sentiments via our Facebook and Google + pages linked below!

You can follow us on Twitter, add us to your circle on Google+ or like our Facebook page to keep yourself updated on all the latest from Microsoft, Google, Apple and the web.

 

 

MOBILE PC - Ubuntu On Android With External PC Screen, Mouse and Keyboard

Taken From: http://www.redmondpie.com/install-and-run-ubuntu-on-your-android-device-with-ubuntu-installer-download-now/

Sunday, June 10, 2012

Changing The Language & Keyboard Layout – Linux Distributions

Version 1.0

Author: Oliver Meyer <o [dot] meyer [at] projektfarm [dot] de>
Last edited 04/03/2008

This document describes how to reconfigure the default language and the keyboard layout on various distributions so that they suit your location. I made this howto for our VMware images where the keyboard layout is always set to German and a few users have problems to configure the language and keyboard layout on these images.

This howto is a practical guide without any warranty - it doesn't cover the theoretical backgrounds. There are many ways to set up such a system - this is the way I chose.

1 Preliminary Note

If you're using a system with a desktop environment like Gnome or KDE you should use its tools to configure the default language and the keyboard layout. In the following steps I'll show you how to change the default language and the keyboard layout within the console on various distributions.

2 Fedora 8 Server / CentOS 5.x

2.1 Default Language

system-config-language

2.2 Keyboard Layout

system-config-keyboard

3 Debian Etch Server

3.1 Default Language

dpkg-reconfigure locales

3.2 Keyboard Layout

dpkg-reconfigure console-data

4 Ubuntu 7.10 Server

4.1 Default Language

sudo set-language-env -E

4.2 Keyboard Layout

sudo dpkg-reconfigure console-setup

5 Mandriva 2008 Server

5.1 Default Language

localedrake

5.2 Keyboard Layout

keyboarddrake

6 Suse 10.X Server

6.1 Default Language

yast2

Select "System" on the left side and then "Language" on the right side. Change the language and save the settings with "Accept"

6.2 Keyboard Layout

yast2

Select "Hardware" on the left side and then "Keyboard Layout" on the right side. Change the keyboard layout and save the settings with "Accept".

 

7 Links

· Fedora: http://fedoraproject.org/

· Debian: http://www.debian.org/

· Ubuntu: http://www.ubuntu.com/

· Mandriva: http://www.mandriva.com/

· Suse: http://www.opensuse.org/

Taken From: http://www.howtoforge.com/changing-language-and-keyboard-layout-on-various-linux-distributions

Monday, February 20, 2012

GNS3 - PIX Firewall Emulation

PIX Firewall Emulation

GNS3 is also capable of emulating PIX firewalls. Once again, you’ll need to provide your own PIX image. If you want to run more than a restricted license, you’ll also need to have a valid serial number and activation keys.

Configuring Qemuwrapper and Cisco PIX image

First, go to Preferences on the Edit menu in GNS3. Click on Qemu in the left pane. The default path to the Qemuwrapper should be fine. You may want to specify a different working directory. Note that Qemuwrapper is shipped with a compiled version of Pemu, therefore you do not need Qemu to emulate PIX.

On PIX tab, use the button next to Binary image to specify the location of your PIX operating system image. You may also change other settings like RAM or the number of interfaces. Once you are finished with the settings, click on Save.

clip_image002clip_image004

You may use the default Key and Serial number, if necessary. This will provide a restricted license with limited features. You will need a valid serial number and activation keys to access additional features. The graphic below on the left is a restricted image. Failover, VPN-DES, and VPN-3DES-AES are disabled. You are also limited to 6 physical interfaces and 25 VLANs. The graphic below on the right is unrestricted. With an unrestricted license, these features are enabled along with support for additional interfaces and VLANs.

clip_image006

If you have a serial number and valid activation keys, you may move from a restricted license to an unrestricted license. Type in the activation keys separated by commas with no spaces. Use all lower case. Be sure your serial number is converted to hexadecimal. It is usually in decimal in a show version command. Use a calculator to convert from decimal to hexadecimal if necessary.

Using Cisco PIX

Click OK to return to the GNS3 main interface. Drag a PIX firewall icon from the Nodes Types pane into the workspace. Right-click FW1 and choose Start, then right-click on FW1 again and choose Console.

Once you console into your PIX firewall, issue a show version command. If the activation keys do not show up properly, then issue the following command from privileged mode (enable mode):

pixfirewall# activation-key 0x12345678 0x12345678 0x12345678 0x12345678

clip_image008

The command is issued on one line with spaces between the activation keys. Save the configuration using either the write command orcopy run start. Stop the device and restart it. Congratulations! Your PIX firewall is up and running.

Interfaces on the PIX are Ethernet interfaces. To connect to other devices, you’ll need to use either Ethernet or FastEthernet interfaces. You may not connect to a serial interface.

You may connect to other PIX firewalls, routers, and switches. You may not connect to a cloud. Consequently, to connect to a real network or to a Virtual PC, you’ll need to connect from the PIX to a switch, and then from the switch to your Cloud.

CPU usage with PIX

Just as with routers, CPU usage is an issue when emulating PIX firewalls on your computer. You will note that your CPU usage is most likely 100%. There are no idle-pc values available for PIX firewalls at this time. Instead, you may use third-party software to control your CPU usage. There are a variety of products on the market. The one that I use for Windows is called BES and is a free download.

Complete documentation is available on the Web site along with the program download. Once you start your PIX firewall, start BES. Click the Target button. Choose the pemu.exe process and click the Limit this button. A confirmation screen will appear.

Click the Control button to control how much CPU limiting will be used. I’ve set mine to reduce CPU usage by 50%. If you are running multiple firewalls, you will want to limit each one. This program may also limit other processes running on your Windows computer.

clip_image010clip_image012

For Linux, use cpulimit. You may learn more about cpulimit at the following Web site: http://cpulimit.sf.net. On ubuntu you can use Synaptic Package Manager or Ubuntu Software Centre to download and install cpulimit.

To run cpulimit, press F2 while holding the ALT key down (ALT+F2) in Ubuntu to open a Run Application box. Type the following in the box:

cpulimit –e pemu –l 40

clip_image014

This will limit the application pemu to 40% CPU usage.

Still in your Ubuntu, choose System Monitor under Administration on the System menu. Click the Resources tab. You should see that pemu process is running at 40% of your CPU usage.

Taken From: http://www.gns3.net/gns3-pix-firewall-emulation/

Tuesday, December 27, 2011

Install Gnome in Ubuntu 11.10 (Unity Desktop)

Here we go again. A new version of Ubuntu is out and if you still don't want to switch from it because of Unity, you are welcome to try and install Gnome. (I didn't try removing or disabling Unity this time, but you are welcome to).
Keep in mind that the new gnome leaves a lot to be desired (like that clock in the middle of the screen) and will take some time to get used to (not as much as Unity though).
Steps:

1. Open shell and run:

     sudo apt-get install gnome-shell

2. Once installed, you have to reboot.

3. After the reboot, on the login window select Gnome classic


clip_image002

An alternative is XFCE, you can either get XUbuntu or do the following:

     sudo apt-get install xubuntu-desktop

I have done this and it works but Gnome looks like crap, I’m seriously considering switching to another distro like MintLinux. CANONICAL please support GNOME again, Unity is good for tablets, but not for the Desktop, you can put Unity in the netbook version off Ubuntu.

Based on: http://www.virtualhelp.me/linux/470-install-gnome-in-ubuntu-1110-oneiric-ocelot

Wednesday, September 23, 2009

Remote Desktop (XDMCP) on Ubuntu

Here I'm going to show you howto activate XDMCP (remote desktop protocol), on Gnome (bash an gui) and KDE. I have tested it only on Gnome so far. Note that this remote desktop protocol does not forwand sound.

Here some notes on the roles of the XDMCP server and client

Server - The remote machine were we want to login.
Client - The local machine were we will login on the Server

Before trying anything on XDMCP, you should make
sure that on the server your firewall is either disabled
or allows Udp port 177.

Here I'm going to show how to open a UDP 177 (rule),
on Iptables (firewall) using the bash, but you use a
very simple and usefull, Gui for Iptables nown as
"Firestarter" (to install on ubuntu just do
sudo apt-get install iptables).

$ sudo iptables -A INBOUND -p udp --destination-port 177 -j ACCEPT

Here are a couple off other usefull comands on Iptables

## Checking Iptables Rules #####
$ sudo iptables -nvL

if you have already executed the rule to open UDP port 177,
by executing this comand, you should see it there.

## Clearing All the Rules #####
$ sudo iptables -F

be aware that this comand clears all off the rules, and this
does not mean that all is allowed, on the contrary,
IPtables default beaviour, when it has no rules is to
deny all, so be very carefull.


XDMCP GNOME - via Bash
=====================================

XDMCP Server Configuration
----------------------------------

## Allowing the remote login on the Server #####
$ sudo gedit /etc/gdm/gdm.conf-custom
...
[xdmcp]
Enable=true
...

You should have the above on the file.

If you want the remote login screen to be the same as
the graphical greeter that is the default in the Ubuntu
install make sure that the following is present.

...
[daemon]
RemoteGreeter=/usr/lib/gdm/gdmgreeter
...

For these changes to take efect you can either,
reboot:

$ sudo reboot

or restart the service, for that go to text terminal (Ctlr+Alt+F2)
and type:

$ sudo /etc/init.d/gdm restart

to go back to you Gnome environment try Ctlr+Alt+F7, or some
Ctlr+Alt+Fx, close to F7.


XDMCP Client Login
------------------------

$ sudo X :1 -query server_ip

After this if all went well you should see
Ubuntu's graphical login screen, as if you
were on the remote computer fisicaly.

If don't want to see it fullscreen, you can
show the remote desktop on a window by
using the following command instead:

$ sudo Xnest :1 -query server_ip


XDMCP GNOME - via Gui
=====================================

This is equivelent to the shown above, the diference
is that, the server here is configured via Gui.

XDMCP Server Configuration
-----------------------------------
Allowing the remote login on the Server


As shown above System > Administration > Login Window



And then change the Style to "Same as Local", and that's it.
Aditional confuguration can be done on "Configure XDMCP"

For these changes to take efect you can either,
reboot:

$ sudo reboot

or restart the service, for that go to text terminal (Ctlr+Alt+F2)
and type

$ sudo /etc/init.d/gdm restart

to go back to you Gnome environment try Ctlr+Alt+F7, or some
Ctlr+Alt+Fx, close to F7.


XDMCP Client Login
------------------------

$ sudo X :1 -query server_ip

After this if all went well you should see
Ubuntu's graphical login screen, as if you
were on the remote computer fisicaly.

If don't want to see it fullscreen, you can
show the remote desktop on a window
by using the following command instead:

$ sudo Xnest :1 -query server_ip


XDMCP KDE - via Bash
(didn't test it, give me feedback if you do)
=====================================

XDMCP Server Configuration
----------------------------------
Still working on it...

XDMCP Client Login
------------------------

$ sudo X :1 -query server_ip

After this if all went well you should see
Ubuntu's graphical login screen, as if you
were on the remote computer fisicaly.

If don't want to see it fullscreen, you can
show the remote desktop on a window
by using the following command instead:

$ sudo Xnest :1 -query server_ip

Based On:

GNOME
http://megaf.wordpress.com/2009/04/15/xdmcp-internet-seu-linux-onde-voce-estiver/
http://stochasticflux.com/blog/?p=4

KDE

http://www.guiadohardware.net/tutoriais/configurando-servidor-xdmcp/pagina3.html
http://megaf.wordpress.com/2009/04/15/xdmcp-internet-seu-linux-onde-voce-estiver/

Iptables
http://www.cyberciti.biz/tips/linux-iptables-open-bittorrent-tcp-ports-6881-to-6889.html

Saturday, September 19, 2009

Remote Applications via X11 - Easy Way (over ssh)

Here I will show you how to interact with applications remotely. This is quite useful when you have for example an Ubuntu Server that doesn't have a graphical environment (Gnome or KDE) and a Desktop that has and you need to use some graphical applications on the Ubuntu Server but you can't because you don't have a graphical environment.

So whit this you can show and interact with the graphical applications on the Ubuntu Server, using your Desktop's, graphical environment. So in the X11 world you have the following:

Ubuntu Server - X11 Client --> Application is executed
Ubuntu Desktop - X11 Server --> Application is shown

It's a bit confusing at first, that your Ubuntu Server is your X11 Client, and you Desktop is the X11 Server.

Note: this was tested on Ubuntu 8.04 and 9.04.

X11 Server - Where the remote apps will be shown
===================================

my_user@my_desktop:~$ ssh -X root@remote_server
root@remote_server:~$

Now you have a what looks like a normal ssh remote terminal on the "remote_server". But when you execute an graphical apps on the remote server it will be displayed on your desktop, for example:

root@remote_server:~$ gedit

With this you can make a text file on your machine tha will be saved on the remote server.

If you want ssh to always act like this, have the following line in your /etc/ssh/ssh_config:

ForwardX11 yes

With this method all the data over the network will be encrypted, because of ssh, but if you want to kick it old school, whit no encryption an a lot more complicated using X11 directly, you can check the post "Run Applications Remotely via X11 - Hard Way"

Based on: http://wiki.linuxquestions.org/wiki/X11_forwarding_with_OpenSSH

Remote Applications via X11 - Hard Way

Here I will show you how to interact with applications remotely. This is quite useful when you have for example an Ubuntu Server that doesn't have a graphical environment (Gnome or KDE) and a Desktop that has and you need to use some graphical applications on the Ubuntu Server but you cant because you don't have a graphical environment.

So whit this you can show and interact with the graphical applications on the Ubuntu Server, using your Desktop's, graphical environment. So in the X11 world you have the following:

Ubuntu Server - X11 Client --> Application is executed
Ubuntu Desktop - X11 Server --> Application is shown

It's a bit confusing at first, that your Ubuntu Server is you X11 Client, and you Desktop is the X11 Server.

Note: this was tested on Ubuntu 8.04 and 9.04.

X Server - 192.168.1.68 (Where the remote apps will be shown)
=======================================
## Allow that the remote applicatilõns to be show on the X11 Server #####
$ sudo gedit /etc/gdm/gdm.conf

DisallowTCP=true
change it to
DisallowTCP=false


## Reboot to load the new gdm.conf file #####
$ sudo reboot


## Check if the X Server TCP Connections ######
$ netstat -natp |grep :6000

(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN -
tcp6 0 0 :::6000 :::* LISTEN -


## Add permission for the remote X Client applications #####
## to be shown locally this is temporary, when you #####
## reboot, you must do this again #####
$ sudo xhost 192.168.1.71

## Find the id of the display you are in currently, #####
## and were we see the remote apps, from the X Clinet #####
$ echo $DISPLAY
:0.0


X client - 192.168.1.71 (Where the remote apps will be executed)
========================================

In order to show an application remotely you should use one of the options bellow, where 192.168.1.68 is the IP of the remote computer were the applications will be shown and 0.0 is the id of the graphical terminal on that computer, found earlier, were the remote applications will be displayed.

In this example we execute the application "nautilus", you should change it to the application you want to see remotely.
$ sudo DISPLAY=192.168.1.68:0.0 nautilus
or
$ sudo export DISPLAY=192.168.1.68:0.0
$ nautilus

some applications will not work with the first option so try the second.

After executing one of the two options above, the applications
will be running locally on the X Client (192.168.1.71) but displayed remotely on X Server (192.168.1.68), the applications will not be able to see or use anything on the X Server, there you can only interact with it, and all the resources it may use are from the X Client (local machine).

For example if you replace "nautilus" with "gedit", write something on it and save it the file will be saved on the X Client and not on the X Server were you are interacting with it.


With this method all the data over the network will not be encrypted, if you want a method with encription and a lot easyer using X11 over ssh, you can check the post "Run Applications Remotely via X11 - Easy Way (over ssh)"


Inspired on:

http://ubuntuforums.org/showthread.php?t=162566
http://www.cisl.ucar.edu/docs/ssh/guide/node29.html
http://www.hackinglinuxexposed.com/articles/20040513.html
http://www.linuxquestions.org/questions/linux-newbie-8/how-do-i-restart-x-without-rebooting-418785/
http://www.linuxplanet.com/linuxplanet/tutorials/857/3/
http://www.codingdomain.com/linux/remote/x11/

Wednesday, July 2, 2008

Graphicall Desktop for Ubuntu Server Edition

If you have installed an Ubuntu Server Edition, the first sing you notice is that you dont have X11, GDM, Gnome or KDE, only a text shell.

Here I'm going to show you howto install the Ubuntu Desktop for the Server Edition.

It's actually quite easy, just type on the bash shell:

$ sudo apt-get install ubuntu-desktop

Now sit down and wait, for apt-get to download and install about 900 packets / 472 MB.

And that it, next time you reboot you have the same Gnome Desktop that in the Ubuntu Desktop Edition.

Booting Thin Clients - Over a Wireless Bridge

Thin Clients Booting over a Wireless Bridge

May 1st, 2008 by Ronan Skehill, Alan Dunne and John Nelson

How quickly can thin clients boot over a wireless bridge, and how far apart can they really be?

In the 1970s and 1980s, the ubiquitous model of corporate and academic computing was that of many users logging in remotely to a single server to use a sliver of its precious processing time. With the cost of semiconductors holding fast to Moore's Law in the subsequent decades, however, the next advances in computing saw desktop computing become the standard as it became more affordable.

Although the technology behind thin clients is not revolutionary, their popularity has been on the increase recently. For many institutions that rely on older, donated hardware, thin-client networks are the only feasible way to provide users with access to relatively new software. Their use also has flourished in the corporate context. Thin-client networks provide cost-savings, ease network administration and pose fewer security implications when the time comes to dispose of them. Several computer manufacturers have leaped to stake their claim on this expanding market: Dell and HP Compaq, among others, now offer thin-client solutions to business clients.

And, of course, thin clients have a large following of hobbyists and enthusiasts, who have used their size and flexibility to great effect in countless home-brew projects. Software projects, such as the Etherboot Project and the Linux Terminal Server Project, have large and active communities and provide excellent support to those looking to experiment with diskless workstations.

Connecting the thin clients to a server always has been done using Ethernet; however, things are changing. Wireless technologies, such as Wi-Fi (IEEE 802.11), have evolved tremendously and now can start to provide an alternative means of connecting clients to servers. Furthermore, wireless equipment enjoys world-wide acceptance, and compatible products are readily available and very cheap.

In this article, we give a short description of the setup of a thin-client network, as well as some of the tools we found to be useful in its operation and administration. We also describe a test scenario we set up, involving a thin-client network that spanned a wireless bridge.

What Is a Thin Client?

A thin client is a computer with no local hard drive, which loads its operating system at boot time from a boot server. It is designed to process data independently, but relies solely on its server for administration, applications and non-volatile storage.

Figure 1. LTSP Traffic Profile and Boot Sequence

Following the client's BIOS sequence, most machines with network-boot capability will initiate a Preboot EXecution Environment (PXE), which will pass system control to the local network adapter. Figure 1 illustrates the traffic profile of the boot process and the various different stages, which are numbered 1 to 5. The network card broadcasts a DHCPDISCOVER packet with special flags set, indicating that the sender is trying to locate a valid boot server. A local PXE server will reply with a list of valid boot servers. The client then chooses a server, requests the name of the Linux kernel file from the server and initiates its transfer using Trivial File Transfer Protocol (TFTP; stage 1). The client then loads and executes the Linux kernel as normal (stage 2). A custom init program is then run, which searches for a network card and uses DHCP to identify itself on the network. Using Sun Microsystems' Network File System (NFS), the thin client then mounts a directory tree located on the PXE server as its own root filesystem (stage 3). Once the client has a non-volatile root filesystem, it continues to load the rest of its operating system environment (stage 4)—for example, it can mount a local filesystem and create a ramdisk to store local copies of temporary files. The fifth stage in the boot process is the initiation of the X Window System. This transfers the keystrokes from the thin client to the server to be processed. The server in return sends the graphical output to be displayed by the user interface system (usually KDE or GNOME) on the thin client.

The X Display Manager Control Protocol (XDMCP) provides a layer of abstraction between the hardware in a system and the output shown to the user. This allows the user to be physically removed from the hardware by, in this case, a Local Area Network. When the X Window System is run on the thin client, it contacts the PXE server. This means the user logs in to the thin client to get a session on the server.

In conventional fat-client environments, if a client opens a large file from a network server, it must be transferred to the client over the network. If the client saves the file, the file must be again transmitted over the network. In the case of wireless networks, where bandwidth is limited, fat client networks are highly inefficient. On the other hand, with a thin-client network, if the user modifies the large file, only mouse movement, keystrokes and screen updates are transmitted to and from the thin client. This is a highly efficient means, and other examples, such as ICA or NX, can consume as little as 5kbps bandwidth. This level of traffic is suitable for transmitting over wireless links.

How to Set Up a Thin-Client Network with a Wireless Bridge

One of the requirements for a thin client is that it has a PXE-bootable system. Normally, PXE is part of your network card BIOS, but if your card doesn't support it, you can get an ISO image of Etherboot with PXE support from ROM-o-matic (see Resources). Looking at the server with, for example, ten clients, it should have plenty of hard disk space (100GB), plenty of RAM (at least 1GB) and a modern CPU (such as an AMD64 3200).

The following is a five-step how-to guide on setting up an Edubuntu thin-client network over a fixed network.

1. Prepare the server.

In our network, we used the standard standalone configuration. From the command line:

sudo apt-get install ltsp-server-standalone

You may need to edit /etc/ltsp/dhcpd.conf if you change the default IP range for the clients. By default, it's configured for a server at 192.168.0.1 serving PXE clients.

Our network wasn't behind a firewall, but if yours is, you need to open TFTP, NFS and DHCP. To do this, edit /etc/hosts.allow, and limit access for portmap, rpc.mountd, rpc.statd and in.tftpd to the local network:

portmap: 192.168.0.0/24
rpc.mountd: 192.168.0.0/24
rpc.statd: 192.168.0.0/24
in.tftpd: 192.168.0.0/24

Restart all the services by executing the following commands:

sudo invoke-rc.d nfs-kernel-server restart
sudo invoke-rc.d nfs-common restart
sudo invoke-rc.d portmap restart

2. Build the client's runtime environment.

While connected to the Internet, issue the command:

sudo ltsp-build-client

If you're not connected to the Internet and have Edubuntu on CD, use:

sudo ltsp-build-client --mirror file:///cdrom

Remember to copy sources.list from the server into the chroot.

3. Configure your SSH keys.

To configure your SSH server and keys, do the following:

sudo apt-get install openssh-server
sudo ltsp-update-sshkeys

4. Start DHCP.

You should now be ready to start your DHCP server:

sudo invoke-rc.d dhcp3-server start

If all is going well, you should be ready to start your thin client.

5. Boot the thin client.

Make sure the client is connected to the same network as your server.

Power on the client, and if all goes well, you should see a nice XDMCP graphical login dialog.

Once the thin-client network was up and running correctly, we added a wireless bridge into our network. In our network, a number of thin clients are located on a single hub, which is separated from the boot server by an IEEE 802.11 wireless bridge. It's not an unrealistic scenario; a situation such as this may arise in a corporate setting or university. For example, if a group of thin clients is located in a different or temporary building that does not have access to the main network, a simple and elegant solution would be to have a wireless link between the clients and the server. Here is a mini-guide in getting the bridge running so that the clients can boot over the bridge:

  • Connect the server to the LAN port of the access point. Using this LAN connection, access the Web configuration interface of the access point, and configure it to broadcast an SSID on a unique channel. Ensure that it is in Infrastructure mode (not ad hoc mode). Save these settings and disconnect the server from the access point, leaving it powered on.

  • Now, connect the server to the wireless node. Using its Web interface, connect to the wireless network advertised by the access point. Again, make sure the node connects to the access point in Infrastructure mode.

  • Finally, connect the thin client to the access point. If there are several thin clients connected to a single hub, connect the access point to this hub.

We found ad hoc mode unsuitable for two reasons. First, most wireless devices limit ad hoc connection speeds to 11Mbps, which would put the network under severe strain to boot even one client. Second, while in ad hoc mode, the wireless nodes we were using would assume the Media Access Control (MAC) address of the computer that last accessed its Web interface (using Ethernet) as its own Wireless LAN MAC. This made the nodes suitable for connecting a single computer to a wireless network, but not for bridging traffic destined to more than one machine. This detail was found only after much sleuthing and led to a range of sporadic and often unreproducible errors in our system.

The wireless devices will form an Open Systems Interconnection (OSI) layer 2 bridge between the server and the thin clients. In other words, all packets received by the wireless devices on their Ethernet interfaces will be forwarded over the wireless network and retransmitted on the Ethernet adapter of the other wireless device. The bridge is transparent to both the clients and the server; neither has any knowledge that the bridge is in place.

For administration of the thin clients and network, we used the Webmin program. Webmin comprises a Web front end and a number of CGI scripts, which directly update system configuration files. As it is Web-based, administration can be performed from any part of the network by simply using a Web browser to log in to the server. The graphical interface greatly simplifies tasks, such as adding and removing thin clients from the network or changing the location of the image file to be transferred at boot time. The alternative is to edit several configuration files by hand and restart all dæmon programs manually.

Evaluating the Performance of a Thin-Client Network

The boot process of a thin client is network-intensive, but once the operating system has been transferred, there is little traffic between the client and the server. As the time required to boot a thin client is a good indicator of the overall usability of the network, this is the metric we used in all our tests.

Our testbed consisted of a 3GHz Pentium 4 with 1GB of RAM as the PXE server. We chose Edubuntu 5.10 for our server, as this (and all newer versions of Edubuntu) come with LTSP included. We used six identical thin clients: 500MHz Pentium III machines with 512MB of RAM—plenty of processing power for our purposes.

Figure 2. Six thin clients are connected to a hub, and in turn, this is connected to wireless bridge device. On the other side of the bridge is the server. Both wireless devices are placed in the Azimuth chamber.

When performing our tests, it was important that the results obtained were free from any external influence. A large part of this was making sure that the wireless bridge was not affected by any other wireless networks, cordless phones operating at 2.4GHz, microwaves or any other sources of Radio Frequency (RF) interference. To this end, we used the Azimuth 301w Test Chamber to house the wireless devices (see Resources). This ensures that any variations in boot times are caused by random variables within the system itself.

The Azimuth is a test platform for system-level testing of 802.11 wireless networks. It holds two wireless devices (in our case, the devices making up our bridge) in separate chambers and provides an artificial medium between them, creating complete isolation from the external RF environment. The Azimuth can attenuate the medium between the wireless devices and can convert the attenuation in decibels to an approximate distance between them. This gives us the repeatability, which is a rare thing in wireless LAN evaluation. A graphic representation of our testbed is shown in Figure 2.

We tested the thin-client network extensively in three different scenarios: first, when multiple clients are booting simultaneously over the network; second, booting a single thin client over the network at varying distances, which are simulated by altering the attenuation introduced by the chamber; and third, booting a single client when there is heavy background network traffic between the server and the other clients on the network.

Figure 3. A Boot Time Comparison of Fixed and Wireless Networks with an Increasing Number of Thin Clients

Figure 4. The Effect of the Bridge Length on Thin-Client Boot Time

Figure 5. Boot Time in the Presence of Background Traffic

Conclusion

As shown in Figure 3, a wired network is much more suitable for a thin-client network. The main limiting factor in using an 802.11g network is its lack of available bandwidth. Offering a maximum data rate of 54Mbps (and actual transfer speeds at less than half that), even an aging 100Mbps Ethernet easily outstrips 802.11g. When using an 802.11g bridge in a network such as this one, it is best to bear in mind its limitations. If your network contains multiple clients, try to stagger their boot procedures if possible.

Second, as shown in Figure 4, keep the bridge length to a minimum. With 802.11g technology, after a length of 25 meters, the boot time for a single client increases sharply, soon hitting the three-minute mark. Finally, our test shows, as illustrated in Figure 5, heavy background traffic (generated either by other clients booting or by external sources) also has a major influence on the clients' boot processes in a wireless environment. As the background traffic reaches 25% of our maximum throughput, the boot times begin to soar. Having pointed out the limitations with 802.11g, 802.11n is on the horizon, and it can offer data rates of 540Mbps, which means these limitations could soon cease to be an issue.

In the meantime, we can recommend a couple ways to speed up the boot process. First, strip out the unneeded services from the thin clients. Second, fix the delay of NFS mounting in klibc, and also try to start LDM as early as possible in the boot process, which means running it as the first service in rc2.d. If you do not need system logs, you can remove syslogd completely from the thin-client startup. Finally, it's worth remembering that after a client has fully booted, it requires very little bandwidth, and current wireless technology is more than capable of supporting a network of thin clients.

Acknowledgement

This work was supported by the National Communications Network Research Centre, a Science Foundation Ireland Project, under Grant 03/IN3/1396.

Ronan Skehill works for the Wireless Access Research Centre at the University of Limerick, Ireland, as a Senior Researcher. The Centre focuses on everything wireless-related and has been growing steadily since its inception in 1999.

Alan Dunne conducted his final-year project with the Centre under the supervision of John Nelson. He graduated in 2007 with a degree in Computer Engineering and now works with Ericsson Ireland as a Network Integration Engineer.

John Nelson is a senior lecturer in the Department of Electronic and Computer Engineering at the University of Limerick. His interests include mobile and wireless communications, software engineering and ambient assisted living.


Taken From: Linux Journal, nº 170 2008 - Thin Clients Booting over a Wireless Bridge, by Kyle Ronan Skehill, Alen Dunne and John Nelson