x11vnc – a real X11 display.

“Sometimes one wants to connect to a real X11 display (i.e. one attached to a physical monitor, keyboard, and mouse: a Workstation or a SunRay session) from far away. Maybe you want to close down an application cleanly rather than using kill, or want to work a bit in an already running application, or would like to help a distant colleague solve a problem with their desktop, or would just like to work out on the deck for a while. This is where x11vnc is useful.”
and here you can find a lot more information: http://www.karlrunge.com/x11vnc/

install x11vnc and then on remote machine as user type:

x11vnc -display :0

and then on your local machine type:

vncviewer IP

XFCE and ecryptfs-utils issue.

I use eCryptfs to encrypting a home directory. After upgrade the ecryptfs-utils package to 103 version. I’m not able to log into XFC using a LightDM, the unlock doesn’t work. The LightDM runs in the loop and displays a login screen
again and again. So, the solution is add the following:

auth optional pam_ecryptfs.so unwrap
password optional pam_ecryptfs.so
session optional pam_ecryptfs.so unwrap

to the /etc/pam.d/lightdm file, or:

common-auth-pc, common-session-pc and common-password-pc files into the /etc/pam.d directory

or using:

pam-config -a --ecryptfs should add it automatically to the proper common-* files.

By the way, the bug was fixed after a few hours by openSUSE maintainer 🙂

Enabling the Global Status Monitor – Data Synchronizer.

In Synchronizer Web admin, click Global Status Monitor to display the instructions for enabling the Global Status Monitor. Initially, the current section of the documentation displays in your browser so that you can enable the Global Status Monitor.

As root in a terminal window, enter the following command:

root#: /opt/novell/datasync/previewfeature.sh --monitor --action enable

Restart the Synchronizer services. Refresh the Synchronizer Web Admin browser window to replace the link to the documentation with the link to the Global Status Monitor.

Recover root password.

1. Boot the LiveCD or rescue CD/USB, and mount your root (/) partition. For example:

mkdir /mnt/root
mount /dev/sdaX /mnt/root

and then edit the password file with your editor:

vim /mnt/root/etc/shadow

and then delete the second field on the root line:

root:$1$KmZw.u7l$JI6aYJRrSU7ZcUivaNQpZ1:15833:0:99999:7:::

2. Boot the LiveCD or rescue CD/USB, and mount your root (/) partition. For example:

mount -o remount,rw /dev/sdaX /mnt/root
chroot /mnt/root
passwd root

3. INIT or /bin/bash mode

Another trick is to add “init=/bin/bash” (LILO “linux init=/bin/bash” or add it to the Grub “kernel” line). This will dump you to a bash prompt much earlier than single user mode, and a lot less has been initialised, mounted, etc. You’ll definitely need the “-o remount,rw” here. Also note that other filesystems aren’t mounted at all, so you may need to mount them manually if you need them. Look in /etc/fstab for the device names.

passwd root

🙂

Understanding I/O streams numbers.

Handle Name Description
0 stdin Standard input
1 stdout Standard output
2 stderr Standard error

Redirecting the standard error stream to a file. The following will redirect program error message to a file called error.log:

$ program-name 2> error.log
$ command1 2> error.log

Redirecting the standard error (stderr) and stdout to file
Use the following syntax:

$ command-name &>file

OR

$ command > file-name 2>&1

Another useful example:
$ find /usr/home -name .profile 2>&1 | more

How to install and set up VPN (PPTP) server on Debian Linux.

PoPToP Point to Point Tunneling Server, this implements a Virtual Private Networking Server (VPN) that is compatible with Microsoft VPN clients. It allows windows users to connect to an internal firewalled network using their dialup.

Install pptpd:

root:# apt-get install pptpd

and then edit the configuration file:

root:# vim /etc/pptpd.conf

and add the following lines to:

localip 192.168.1.144
remoteip 192.168.1.200-225, 192.168.1.230

# Specifies the local and remote IP address ranges.
#
# Any addresses work as long as the local machine takes care of the
# routing. But if you want to use MS-Windows networking, you should
# use IP addresses out of the LAN address space and use the proxyarp
# option in the pppd options file, or run bcrelay.

then edit the configuration file:

root:# vim /etc/ppp/pptpd-options

and add the following lines to:

ms-dns 192.168.1.44 # my DNS server
nobsdcom
noipx
mtu 1490
mru 1490

edit another one configuration file:

root:# vim /etc/ppp/chap-secrets

and add the following lines to:

username * password *

then restart the pptpd service:

root@server: service pptpd restart

and don’t forget to enable 1723 on a firewall.

Data Synchronizer Mobility Connector and a self-signed cert.

In order to be able to use Mobility Pack with a self-signed cert (normally for testing purposes), you’ll need to follow these instructions: NOTE: You can name the .key and .cert files anything you’d like initially because you’re going to need to change it to “mobility.pem” later. Open the terminal and perform the following commands:

openssl genrsa 1024 > anything.key
chmod 400 anything.key
openssl req -new -x509 -nodes -sha1 -days 365 -key anything.key > anything.cert

Now that you’ve created the key and cert file you need to concatenate the two files into a .pem file with this command, private key first, then cert. You can also remove the .key file for security purposes in the same command.

cat anything.key anything.cert > anything.pem && rm anything.key
chmod 400 anything.pem

Once you’ve created the .pem file you need to rename it to “mobility.pem” and then replace it with the mobility.pem file in /var/lib/datasync/device.
WinMobile devices require a .cer certificate file (as opposted to .pem). You’ll need to create a copy of the .pem file and convert it to .cer:

openssl x509 -in mobility.pem -inform PEM -out mobility.der -outform DER

rename the mobility.der to mobility.cer and move it in the /var/lib/datasync/device directory.
Restart the connectors and resync with your device, now you shouldn’t have cert issues with your device while trying to connect with your self-signed cert.

Debian 7.0 was released May 4th, 2013.

May 4th, 2013

After many months of constant development, the Debian project is proud to present its new stable version 7.0 (code name “Wheezy”).
This new version of Debian includes various interesting features such as multiarch support, several specific tools to deploy private clouds, an improved installer, and a complete set of multimedia codecs and front-ends which remove the need for third-party repositories.

Multiarch support, one of the main release goals for “Wheezy”, will allow Debian users to install packages from multiple architectures on the same machine. This means that you can now, for the first time, install both 32- and 64-bit software on the same machine and have all the relevant dependencies correctly resolved, automatically.

The installation process has been greatly improved: Debian can now be installed using software speech, above all by visually impaired people who do not use a Braille device. Thanks to the combined efforts of a huge number of translators, the installation system is available in 73 languages, and more than a dozen of them are available for speech synthesis too.
In addition, for the first time, Debian supports installation and booting using UEFI for new 64-bit PCs (amd64), although there is no support for “Secure Boot” yet.

Debian is a free operating system, developed by thousands of volunteers from all over the world who collaborate via the Internet. The Debian project’s key strengths are its volunteer base, its dedication to the Debian Social Contract and Free Software, and its commitment to provide the best operating system possible. Debian 7.0 is another important step in that direction.

The code name for the next major Debian release after wheezy is “jessie”.

This release started as a copy of wheezy, and is currently in a state called “testing”. That means that things should not break as badly as in unstable or experimental distributions, because packages are allowed to enter this distribution only after a certain period of time has passed, and when they don’t have any release-critical bugs filed against them.

Well now, my servers have been updated to “wheezy” 😀

TightVNC Remote Desktop Connections using SUSE as Client or Server.

1. Install the tightvnc and xorg-x11-Xvnc packages:

root# zypper install tightvnc xorg-x11-Xvnc

Type the command vncserver to start the VNC server, and then type the command
vi $HOME/.vnc/xstartup
to open the VNC configuration file in the vi text editor. You can replace “vi” with your preferred text editor.
Add the line /usr/bin/gnome & under the #!/bin/sh line, if you are using the Gnome desktop.

Type the command vncserver in Suse 10 or dbus-launch vncserver in Suse 11, to start the VNC server. Take note of the desktop number, usually “:1,” “:2” or “:3,” that is shown after the command is executed.

2. Connect to the Server

Open the VNC viewer software on the remote computer. Type “192.168.1.100:1” in the connection text box. Replace “192.168.1.100” with the IP address of the Suse server. Replace “:1” with the desktop number from the previous section. and then type the password for the VNC server, when prompted.

Users who are logged on can start a server with a simple console command.

• Starting the server in Suse versions 10.x: vncserver
• Starting the server in Suse versions 11.x: dbus-launch vncserver

The vncserver command will start the next unused desktop in the sequence :1, :2, :3 …etc. You can attach many options to the command line when starting the server. There are options specific to TightVNC on the TightVNC man page and you can also attach the options listed in the Xvnc man page.

Note: vncpasswd allows you to set the password used to access VNC desktops. Its default behavior is to prompt for a VNC password and then store an obfuscated version of this password to passwd-file (or to $HOME/.vnc/passwd if no password file is specified.) The vncserver script runs vncpasswd the first time you start a VNC desktop, and it invokes Xvnc with the appropriate -rfbauth option. vncviewer can also be given a password file to use via the -passwd option. The password must be at least six characters long (unless the -f command-line option is used– see below), and only the first eight characters are significant. Note that the stored password is not encrypted securely – anyone who has access to this file can trivially find out the plain-text password, so vncpasswd always sets appropriate permissions (read and write only by the owner.) However, when accessing a VNC desktop, a challenge-response mechanism is used over the wire making it hard for anyone to crack the password simply by snooping on the network.

conf example:


server:/home/user/.vnc # cat xstartup
#!/bin/sh

[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
twm &