android blackberry

Workers today are more mobile than ever, so providing a secure link to your network for remote workers is crucial. Luckily, it’s also free and easy with OpenVPN. I’ll walk you through the process of setting up an OpenVPN server to authenticate and encrypt multiple client connections in just slightly more time than it takes to read this article.
In the olden days, OpenVPN was a typical nerdy free software project focused on good code rather than marketing, with a plain website devoid of glitz. Today it still has good code, but it has spun off several commercial options and boatloads of glitz. The free-of-cost community GPL edition is the beloved OpenVPN of old, but in addition you can install commercial options and add-ons such as the Access Server for Linux, Access Server Virtual Appliances for Linux, Mac, and Windows, Access Server Cloud Machines, and an Internet Private Tunnel service for Mac and Windows clients. Clients on all major platforms sport nice graphical interfaces, and there are several management GUIs, some standalone and some integrated into other products, such as DD-WRT, IPCop, and Zentyal.
We’ll set up the GPL community version on Linux. GUIs and extra services are nice conveniences, but admins should understand what’s happening under the hood, and OpenVPN has never been all that difficult to deploy, even without the glitzy helpers.
To get started, you will need at least two Linux PCs, with OpenVPN installed on each: one for the server and one (or more) for the client. OpenVPN is included in nearly all Linux distributions, so fire up your favorite package manager to install it. Source and binary downloads are also available.

Creating a Public Key Infrastructure

Your first step in setting up OpenVPN is to create a public key infrastructure (PKI). OpenVPN uses mutual authentication – the server and client authenticate to each other, which provides a strong level of security that protects both sides of the connection. Each client and server has a pair of keys – a public key for encrypting communications, and a private key for decrypting. Public keys are meant to be shared, while private keys must be protected and never shared. You’re probably familiar with key pairs from having used them to authenticate in SSH and SSL. To make things easier, we’ll use a certificate authority (CA) to sign clients’ key pairs. Without a CA, the server would need to store a copy of every client certificate. With one, the server holds the CA’s own key pair and a server key pair, and each client has its own key pair. The server doesn’t need to know anything about those client certificates; all it knows is whether the CA signed the client certificates.
In OpenVPN the public key is called a certificate and has a .crt extension. The private key is called a key, with a .key extension.
OpenVPN comes with nice helper scripts to set up this PKI. On my Debian Wheezy system the scripts are in /usr/share/doc/openvpn/examples/easy-rsa/2.0; on your Linux flavor they may be somewhere else. Once you hunt them down, copy the whole directory to /etc/openvpn so that the package manager will not overwrite your changes:

# cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0 /etc/openvpn/

On my system this creates /etc/openvpn/2.0. Change to your copied directory, then find a file named vars and edit the last section so that it contains your correct location, email address, and other identifying information. Feel free to examine the other options and change them if you wish, though everything should work fine with the defaults. Here’s how mine looks:

# These are the default values for fields
# which will be placed in the certificate.
# Don't leave any of these fields blank.
export KEY_COUNTRY="US"
export KEY_PROVINCE="OR"
export KEY_CITY="LittleBigtown"
export KEY_ORG="Tuxcomputing"
export KEY_EMAIL="carla@bratgrrl.com"
export KEY_EMAIL=carla@bratgrrl.com
export KEY_CN=test-system
export KEY_NAME=test-system-key
export KEY_OU=test-system
export PKCS11_MODULE_PATH=changeme
export PKCS11_PIN=1234

Now run the following commands:

#. ./vars
#./clean-all
#./build-ca
Generating a 1024 bit RSA private key
....................++++++
.......++++++
writing new private key to 'ca.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [US]:
State or Province Name (full name) [OR]:
Locality Name (eg, city) [LittleBigtown]:
Organization Name (eg, company) [Tuxcomputing]:
Organizational Unit Name (eg, section) [test-system]:
Common Name (eg, your name or your server's hostname) [test-system]:
Name [test-system-key]:
Email Address [carla@bratgrrl.com]:

Look in the keys/ subdirectory to see your new root CA certificate and root CA key, ca.crt and ca.key. ca.crt is publicly readable, while ca.key must never be shared. Now build the server’s private key pair, specifying whatever name you want to use for your system. Every time you create a server key it must have a unique name to identify the system it is created for:

# ./build-key-server test-system

This process is similar to creating the CA. When it offers the option to create a challenge password, say no. Say yes to these questions:

Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y

Now your server certificate is properly signed by your CA. Every client will get a copy of ca.crt, and thus be able to verify that they are connecting to the correct server.

Client Certificates

Next, you must create client certificates with the build-key or build-key-pass scripts. Use the first to create a password-less certificate, and the second to require your users to enter a password when they connect to the VPN. A password might be a wise precaution for mobile users. Use these commands just like the build-key-server script, with a unique name for each client:

# ./build-key lucy
# ./build-key ricky
# ./build-key-pass ethel
# ./build-key fred

One more chore is generating the Diffie-Hellman parameters. What, you and I and all normal humans ask, the heck are those? Diffie-Hellman is the protocol that allows two users to exchange a secret key over an insecure medium without any prior secrets, which is pretty cool, I think. Back at the OpenVPN server, run this command:

# ./build-dh

All you have to do is wait for it to finish; it creates a file called 01.pem.
All of your new keys and certificates are in plain text, so you can read them if you forget what they’re for. Now copy to each client the file ca.crt, plus the appropriate client certificates and keys.

Server Configuration

The next step is to create the server and client configuration files. Look in your installation’s openvpn/examples/ directory for configuration file examples. They are well-commented and easy to follow. Listed below is a complete example server configuration, /etc/openvpn/server.conf. The commented options take variables specific to your setup. Read the example file to learn about the other options:

port 1194
proto udp
dev tun

# the full paths to your server keys and certs
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/test-system.crt
key /etc/openvpn/keys/test-system.key
dh /etc/openvpn/keys/01.pem

cipher BF-CBC

# Set server mode, and define a virtual pool of IP
# addresses for clients to use. Use any subnet
# that does not collide with your existing subnets.
# In this example, the server can be pinged at 10.8.0.1
server 10.8.0.0 255.255.255.0

# Set up route(s) to subnet(s) behind
# OpenVPN server
push "route 192.168.10.0 255.255.255.0"
push "route 192.168.11.0 255.255.255.0"

ifconfig-pool-persist /etc/openvpn/ipp.txt
keepalive 10 120
status openvpn-status.log
verb 6

Client Configuration

Once you have the server set up, create a similar configuration file on your test client, /etc/openvpn/client.conf:

client
dev tun
proto udp

# enter the server's hostname
# or IP address here, and port number
remote test-system 1194

resolv-retry infinite
nobind
persist-key
persist-tun

# Use the full filepaths to your
# certificates and keys
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/lucy.crt
key /etc/openvpn/keys/lucy.key

ns-cert-type server
comp-lzo
verb 6

Connecting to the Server

Now everything should be properly configured. Start OpenVPN on both the server and client from the command line on each system by referencing the configuration file – for example, openvpn /etc/openvpn/server.conf. You’ll see all kinds of startup messages. When it’s finished, you should be able to ping the server’s virtual address from the client, which is 10.8.0.1 in the example server configuration file. When your client and server can ping back and forth, you have a good stout encrypted OpenVPN tunnel.
Congratulations – you just got OpenVPN up and running. Now you get to figure out how to route your OpenVPN clients through your firewall to your server, how to set up your server to start automatically at boot time, and how to configure the clients to manage starting and stopping an OpenVPN session. To help with some of that, a good OpenVPN plugin for NetworkManager called network-manager-openvpn makes managing Linux OpenVPN clients as easy as any other network login. Visit OpenVPN.net for help, more graphical client and server administration tools, and to learn more about OpenVPN and what it can do.

    This tutorial shows how to convert an existing CentOS VM to a Physical machine. This tutorial covers the cloning of the VM to an unpartitioned HDD and troubleshoot some of the possible errors that you may have booting the OS on your new hardware. To illustrate this procedure I will use VMware Workstation 7 as the handler to transfer the VM installation to a physical HDD.

1 Requirements

To perform this procedure you will need:

• VMware Workstation, VMware Server or VMware Player.
• CloneZilla ISO image.
• Unpartitioned HDD with enough space to hold your VM image.

2 Preliminary Notes

This tutorial assumes basic knowledge of the cloning process and requires no previous experience on the use of Clonezilla. Make sure your OS is not using in any way the target HDD that will hold your final copy of the VM, otherwise VMware will complain about your disk been in use and CloneZilla will not perform a successful copy of the VM.

3 VMware Configuration

First thing is to make sure your virtual CD/DVD is using your CloneZilla ISO image to boot. Next add your physical HDD as part of your existing VM by clicking the Add button.

Select Hard Drive and click Next.

Select Use physical disk (for advanced users) then click Next.

Make sure you select the correct drive that you want to use for your physical disk and select the option Use entire disk.

Finally give a name to your configuration file then click Finish.

Make sure your final VMware hardware list include this two elements otherwise, start all over.

4 CloneZilla Cloning Process

Start your VMware and boot from your virtual ISO into CloneZilla image. Use the Live option with default settings.


Select your preferred language and continue.


Accept the default option Don't touch keymap and continue.


Select Stat_clonezilla and continue.


Select device-device option and continue.


Select Beginner mode and continue.


Select disk to local disk and continue.


Select your source disk and click OK.


Select your target disk and click OK, then press Enter to continue.


You will be presented with a warning, about your existing data on your target disk will be lost, make sure there's nothing usable on your disk before you continue.


You will be presented with a series of questions answer yes to all this prompts.


The cloning process may take a long time.


After the cloning process is finished hit Enter and power off the VM by pressing 0 on the CloneZilla menu.


The cloning process is complete, is now time to install your new HDD to your physical machine.

5 Troubleshooting Physical Machine

More likely your first encounter with your cloned OS will be a filesystem corruption, with the following error: Unexpected Inconsistency. To fix this problem enter your root password and run fsck -y to start the filesystem repair process. The -y answers yes to the questions the fsck command will probably output.


Your next challenge will be fixing your NIC, I have used two different methods to fix this problem.
Go into /etc/udev/rules.d and delete the file 70-persistent-net.rules then reboot. Deleting the file forces the detection process to run again at boot with no baggage left over from the cloning process.
The other way to fix this problem is by edit: /etc/sysconfig/network-scripts/ifcfg-eth0 and add the MAC address of your new NIC.
Open eth0 using vi, type:
Edit the following line:
This is my sample config file:

# Micro-Star INT'L CO Gigabit Ethernet Controller
DEVICE=eth0
BOOTPROTO=static
DHCPCLASS=
HWADDR=00:19:B1:2A:BA:B8
IPADDR=10.10.11.50
NETMASK=255.255.255.192
ONBOOT=yes

Save and close the file then reboot the server:
The system is now ready to be used.

6 Links

CloneZilla: http://clonezilla.org/

Basic Linux system auditing is a bit tricky and data collected and information of that is out of place and readability is not that good. Recently this lead me to put together a Open Source code project and develop simple BASH scripts that do the job nicely.
The code and tar ball can be downloaded from both google code or from SourceForge's website and the project website has links to documentation, help, installation and code.
The Auditor utilities can be safely copied/extracted into /usr/local/bin as this folder is in the path settings in most linux distributions. The utilities work well with the latest versions of RHEL, FEDORA, CENTOS, OPENSUSE, UBUNTU, DEBIAN, SLACKWARE.

Download And Install

At the shell prompt as root and these scripts will only keep one process and only as root:
Does a dependency check, i.e. the utility will check if the system has got the necessary apps installed, a few are ip, grep, awk, netstat etc. which are mostly part of the base system.
This should give you a list of dependency error list. The available Auditors features explained at end of page and their syntax are:
The audited data is copied into a file in /tmp//filename and a tmp folder cleaner is provided.
An additional utility that is bundled along is the password generator:

Download

http://code.google.com/p/linux-easy-admin-utilities/
http://sourceforge.net/projects/lnxesyadmutil/
Website:
http://linux-easy-admin-utilities.blogspot.com/

Features

genadtchk - General Audit Checker: This script generates a simple information information about your system. Basic system, Memory, Disk, File System, Network data is audited.
dksadtchk - Disk Audit Checker: This script generates a complete and compressive information about your systems disk and storage. Total disks at boot time, contained partitions, partitions used, removable disks, capacity and free capacity etc.
fsadtchk - File System Audit Checker: This script generates a complete and compressive information about the systems FS usage and current mounted, total available, type, size, free, and space occupying number one folder or file from the FS.
netadtchk - Network Audit Checker: This script  generates a complete and compressive information about the network interfaces - hardware, virtual, local and other , firewall and its status, outgoing firewall status, current process that are having listening processes, port - ip - process - executable table, IPV4/6 feature, forwarding, masquerading for the system.

  Systemd, Lennart Poettering's new init system that is taking the Linux world by storm, is all full of little tricks and treats. Today we will play the slow-boot blame game, and learn to how stop services so completely the poor things will never ever run again.

Stomping Services

In the olden days of sysvinit there were several ways to stop a service:

• Temporarily from the command line, like /etc/init.d/servicename stop, or service servicename stop
• Changing its startup link in /etc/rcn.d from Sfoo to Kfoo
• Remove all init scripts
• Which didn't always do the job because sometimes there lurked a script to automatically restart it that bypassed the init scripts, so you had to hunt this down and change it

In Managing Services on Linux with systemd we learned how systemd simplifies starting and stopping services, both per-session and at boot. systemd has one more way of stopping services, and that is stopping them so completely they will never start again. Or at least not until you change your mind and make them start again. This is how to stop a running service temporarily:
# systemctl stop servicename.service
This stops it from starting at boot, but does not stop a running service:
# systemctl disable servicename.service
That also prevents it from being started by anything else, such as plugging in some hardware, or by socket or bus activation. But you can still start and stop it manually. And there is one way to really really stop a service for good, short of uninstalling it, and that is masking it by linking it to /dev/null:

# ln -s /dev/null /etc/systemd/system/servicename.service
# systemctl daemon-reload

When you do this you can't even start the service manually. Nothing can touch it. After being vexed by mysterious scripts that sneaked around behind my back and restarted services I wanted killed on sysvinit distros, I like this particular command a lot. The unit files in /etc/systemd/system override /lib/systemd/system, which have the same names. Unless your chosen Linux distro does something weird, /etc/systemd/system is for sysadmins and /lib/systemd/system is for your distro maintainers, for configuring package management. So masking should survive system updates.
What if you change your mind? Pish tosh, it's easy. Simply delete the symlink and run systemctl enable servicename.service.
While we're here, let's talk about two reload commands: daemon-reload and reload. The daemon-reload option reloads the entire systemd manager configuration without disrupting active services. reload reloads the configuration files for specific services without disrupting service, like this:
# systemctl reload servicename.service
This reloads the actual configuration file used by the hardy sysadmin, for example the /etc/ssh/sshd_config file for an SSH server, and not its systemd unit file, sshd.service. So this is what to use when you make configuration changes.

Pointing the Finger of Slow Boot Blame

Boot times seem to be an even bigger obsession than uptimes for some folks, and a lot of energy is going into trimming boot times. The time it takes for a PC to boot is controlled by two things: how the long the BIOS takes to do its part, and then the operating system.

There isn't much we can do about BIOS times. Some are fast, some are slow, and unless you're using a system with OpenBIOS you're at the mercy of your motherboard vendor. The PC BIOS hasn't advanced much since its inception lo so many decades ago, except for recurring attempts to lock users out and control what we can install on our own computers, which I think is pretty sad. With quad-core systems as common as dust mites it seems a computer should boot as fast as flicking a light switch.
But I digress, because we're supposed to be talking about systemd. systemd reports to the syslog a boot-time summary, like this example from Fedora 16 XFCE in /var/log/messages:
Jan 09 06:30:13 fedora-verne systemd[1]: Startup finished in 2s 817ms 839us (kernel) + 4s 629ms 345us (initrd) + 1min 11s 618ms 643us (userspace) = 1min 19s 65ms 827us
So this shows that the kernel was initiated in 2 seconds and change, initrd took 4 seconds and change, and and everything else took over a minute nineteen seconds. For all we've been hearing how sysvinit is like all slow and systemd is supposed to be faster, this seems like a long time. (Though it is faster than Windows 7 on the same machine, which needs 6 minutes to completely load all the OEM crap- and ad-ware.) So what's taking so long? We can find out with the systemd-analyze blame command, as this snippet shows:

$ systemd-analyze blame
  60057ms sendmail.service
  51241ms firstboot-graphical.service
  3574ms sshd-keygen.service
  3439ms NetworkManager.service
  3101ms udev-settle.service
  3025ms netfs.service
  2411ms iptables.service
  2411ms ip6tables.service
  2173ms abrtd.service
  2149ms nfs-idmap.service
  2116ms systemd-logind.service
  2097ms avahi-daemon.service
  1337ms iscsi.service

Sendmail? Firstboot graphical service? Iptables? Avahi? Iscsi?? This is from a fresh Fedora installation, so I have a lot of housecleaning to do. There are some limitations to this command: it doesn't show which services start in parallel or what's holding up the ones that take longer. But it does show me a lot of slow services that don't need to be running at all on my system.
If you like pretty graphs systemd includes a cool command for automatically generating an SVG image from the blame output, like this:
$ systemd-analyze plot > graph1.svg
You can view this nice graph in the Eye of GNOME image viewer, or GIMP via the SVG plugin. Figure 1 shows what it looks like.
This doesn't tell you much more than the text output of systemd-analyze blame, but it looks pretty and might give you some clues where the bottlenecks are.

The Android platform is arguably one of the most flexible mobile operating systems in the customization stakes. Almost every part of the Android interface can be modified to meet the requirements of the user without having to gain privileged control (often referred to as "root access"). Customization extends far beyond simply changing the wallpaper, sounds, and widgets.

When the Home button on an Android phone is pressed, the stock launcher is displayed. Whilst the concept of this launcher is well thought out, its implementation is not to everyone's taste. Fortunately, there are a whole raft of home replacement applications available for Android, ranging from the slickest and most feature-laden launchers, to the decidedly weird and wacky.

Given the plethora of software, the purpose of this article is to provide an insight into the best free home replacement apps available for the Android platform. Hopefully, there will be something here that will rejuvenate your phone, however old it is.

Now, let's explore the 8 launchers at hand. For each title we have compiled its own portal page, a full description with an in-depth analysis of its features, screenshots of the software in action, together with links to relevant resources and reviews. We give our highest recommendation to LauncherPro, ADW.Launcher, and GO Launcher EX.

Launchers
LauncherPro	Super-smooth home app replacement
ADW.Launcher	Jam packed with features, eye candy, functions and hugely customizable
GO Launcher Ex	Brings a fresh and extraordinary mobile operation experience
Zeam Launcher	Minimalistic and lightweight launcher
MXHome Launcher	Sports a 3D cover page and a classy coffee theme
QQLauncher Pro	Good screen and program management
Launcher 7	Windows Phone 7 style launcher for Android
HelixLauncher	Extends the functions of Launcher