Use PEAR Through a Proxy

Need to use pear through a proxy?

Type the following in your terminal:

pear config-set http_proxy http://user:password@your_proxy_host.com:8080

You can test by trying a pear search:

pear search Mail

If you see an output similar to the below...:

WARNING: channel "pear.php.net" has updated its protocols, use "pear channel-update pear.php.net" to update
Retrieving data...0%
....50%....Matched packages, channel pear.php.net:
=======================================
Package          Stable/(Latest) Local
Mail             1.2.0 (stable)  1.2.0 Class that provides multiple interfaces for sending emails
Mail2            0.1.1 (beta)          Class that provides multiple interfaces for sending emails
Mail_IMAP        1.1.0RC2 (beta)       Provides a c-client backend for webmail.
Mail_IMAPv2      0.2.1 (beta)          Provides a c-client backend for webmail.
Mail_Mbox        0.6.3 (beta)          Read and modify Unix MBOXes
Mail_Mime        1.10.0 (stable)       Mail_Mime provides classes to create MIME messages.
Mail_mimeDecode  1.5.5 (stable)        Provides a class to decode mime messages.
Mail_Queue       1.2.7 (stable)        Class for put mails in queue and send them later in background.
Net_Vpopmaild    0.3.2 (beta)          Class for accessing Vpopmail's vpopmaild daemon
Services_Mailman 0.1.0 (beta)          Integrates Mailman into a website using PHP

...that means pear is now working. Keep in mind, your password has been stored in the shell's history. Delete it by typing history, find the line number and use:

history -d <line_number>

So, if the line is 51, use:

history -d 51

Read More

Convert a .p12 Keystore to .jks

The below steps seem to be a headache at my workplace. Learn to go from a p12 to jks keystore in this easy tutorial.

In step 1, we will generate the certificates required to build a p12 keystore. In step 2, we will build the .p12 keystore. Then in step 3, we will convert the p12 to a jks keystore. Make sure you are in the correct directory before running the commands. Depending on your installation of Java, it is not the path, you will need to go to the java directory to run ./keytool.

Step 1 - Generate the Certificates:

# Generate Private Key (the master key) in OpenSSL:

openssl genrsa -out johnghawi.com.key 2048

# Generate CSR (Certificate Signing Request - used to get the public certificate) from the Private Key above:

openssl req -new -key johnghawi.com.key -out johnghawi.com.csr

Submit the .csr file to a Certificate Authority (CA) and get your .cer certificate (ASCII/text). The .cer file is your public-facing certificate.

Once you get your host's certificate, you'll likely have been given a one or more intermediate certificates and a root certificate to download as well. Download those as well. What you have, is a chained certificate. It means the intermediates and root certificates are used to complete the chain of authority. In English, the certificate you were given may have been issued by a third-party company. That company may not be in your application's or browser's Trust Store. However, a major Certificate Authority will be in that Trust Store. The certificate that the major CA will have in there is known as a root certificate and it is used to validate the intermediate certificates. In turn, the Intermediates validate the certificate issued to you, and that my friends, is how you complete the chain.

Next, 'bundle' the intermediates and root into one file using the cat command. This step makes managing the certs both easy and central. The certs must be text-based. Do not add your host cert to the line below, only add the intermediates (all of them in order) and the root certificate.

cat intermediate1.cer intermediate2.cer root.cer > chain-bundle.cer

Using a text editor, you can take a look in the chain-bundle.cer file to see your results. Just type:

cat chain-bundle.cer

Step 2 - Build the .p12 Keystore

Before performing the conversion, we will build our p12 keystore in the first command. There is a good chance you arrived here because you wanted to just convert from one to the other. We will build the p12 keystore to illustrate how the OpenSSL keystore maps to the Java keytool keystore. If you have the prerequisite to convert, skip to step 3.

Create .p12 keystore with the certificates from above:

openssl pkcs12 -export -in johnghawi.com.cer -name applet -CAfile chain-bundle.cer -chain -inkey johnghawi.com.key -out myKeys.p12

Step 3 - Convert the p12 keystore to a java keystore (jks):

Depending on how keytool was installed, you may need to add ./ before keytool, such as: ./keytool

keytool -importkeystore \
-deststorepass 123456 -destkeypass 123456 -destkeystore myKeys.jks \
-srckeystore myKeys.p12 -srcstoretype PKCS12 -srcstorepass 123456 -alias applet

Let's find out what each switch in the above command means (you can find this by typing: man keytool at the terminal):
keytool is the 'java keytool' application we are using to perform the function.
-importkeystore tells keytool we are importing contents from another keystore - we don't pass any values here. It only signals to keytool the sub-function we are performing.
-deststorepass 123456 is the password (123456) of the destination jks keystore we are converting to.
-destkeypass 123456 ..when working with PKCS12 keystores, deststorepass and destkeypass need to be the same (see man keytool). This may not be necessary when going from PKCS12 to JKS but I had no issues doing it this way.
-destkeystore myKeys.jks is the path to the Java keystore we will be creating.
-srckeystore myKeys.p12 is the path of the openssl p12 keystore we created earlier.
-srcstoretype PKCS12 is the keystore type of the source openssl keystore we are importing from.
-srcstorepass 123456 the password to open and retrieve from the openssl p12 keystore.
-alias applet is the alias I used in my keystore. Most people use '1' but it helps to make it something useful for when you read the keystore at a later date.

If you've got any questions, feel free to use the comment section below.

Read More

Create Java Keystore Using OpenSSL and Keytool for JBOSS

Last week, I encountered an irritating issue getting JBoss to accept my Java Keystore. The .csr was OpenSSL-generated and the certs were derived from VeriSign. The error I would receive on start:

JBWEB003043: Error initializing endpoint: java.io.IOException: 
JBWEB002000: Alias name 1 does not identify a key entry

The steps below eventually got me up and running. Some parts may look counter-intuitive because instead of converting the keystores to a jks-supported format (doing so kept throwing the above error), I took the certs, put them in an OpenSSL keystore,  and then fed that keystore into the conversion.

In this process, I noticed that creating an empty JKS (JKS = Java KeyStore) would automatically create a key in the new .jks. Though I had my key as alias 1, JBoss would tell me it couldn't find what it was looking for.

If you're running into any of what I'm saying, try the below. If you're here to learn, a keystore is your bag and you want to put your certs in the bag. But there are two types of bags, there is the OpenSSL bag and there is the Java KeyStore bag. They are the two coworkers you have that pretend to like each other, one makes more of an effort to get along with the other,  and deep down, everyone in the office finds dealing with them a little touchy.

Let's start fresh:
1. Concatenate both intermediate and root certs (make sure all your certs are in text format). If you can open all your certs in a text editor and see ASCII characters, you're set. If you cannot, perform the below command on each cert.

# Convert certs from data to text (pem) replacing the values below. Keep track of their names. You need to know which cert is which:

openssl x509 -in <NonTextCert.crt> -inform der -outform pem -out <OutputTextCert.pem>

2. You may not have two intermediate certs. In most cases, you'll have one intermediate (your issuer) and the root certificate (known as the CA - Certificate Authority). In this example, there are two intermediates and a root that we will combine into one file called chain.crt:

cat Primary-Intermediate.pem Secondary-Intermediate.pem VeriSign-Root.pem > chain.crt

To ensure there are no Windows carriage returns in the file, use dos2unix to clean it up:

# Ubuntu:
sudo apt-get install dos2unix

# RedHat:
sudo yum install dos2unix

# Clean up:
dos2unix chain.crt

Here is where the fun begins!

3. Use keytool to generate a Java Keystore. Of course, you'll need the JDK to use the Java keytool. When you create the .jks, a key will be generated inside - a key that we don't want since we have existing keys we want to use. Each command is one line, but I broke the command up at whitespaces to make it easier to read. Change the values to yours.

# Use keytool to generate a jks:

./keytool -genkey -alias tempalias -keyalg RSA -keysize 2048 \
   -dname "CN=johnghawi.com, OU=IT, O=Company, L=Toronto, ST=Ontario, C=CA" \
   -keypass changeit \
   -keystore mykeystore.jks \
   -storepass changeit

4. Remove the unwanted key from mykeystore.jks.

./keytool -delete -alias tempalias -keystore mykeystore.jks -storepass changeit

5. Use 'openssl' to generate a .p12 keystore (the OpenSSL equivalent of a JKS) with all the certs that we will want in the java keystore from above. server.p12 will be the name of the OpenSSL keystore.

openssl pkcs12 -export \
   -out server.p12 \
   -inkey johnghawi-private.key \
   -in johnghawi-public.pem \
   -certfile chain.crt

6. Use keytool to import the .p12 keystore into the java keystore.

# keytool will take the srckeystore server.p12, convert its contents and store it in the 
# original .jks we created in Step 3. By default, the pkcs12 (.p12) keystore entry will be created under alias 1. Instead of supplying the below command with -alias, we will be more precise and explicitly specify the source and dest aliases, should you wish to change it in the destination keystore.

./keytool -importkeystore \
   -deststorepass changeit \
   -destkeypass changeit \
   -destkeystore mykeystore.jks \
   -srckeystore server.p12 \
   -srcstoretype PKCS12 \
   -srcstorepass changeit \
   -srcalias 1
   -destalias 1

At this point, the .jks is ready to use. Copy it to the location you want, secure those permissions and ownership if needed, and specify the keystore in the JBoss config.

 
# Add the new keystore into the config. Your path may differ.
vi $JBOSS_HOME/<instance>/configuration/standalone-full-ha.xml

Find the subsystem tag that contains 'connector name="https" - this will be the tag that will use the jks for web communications. Your alias in the config below needs to match the keystore alias used during the import as well as password:

<connector name="https" protocol="HTTPS/1.1" scheme="https" socket-binding="https" enable-lookups="false" secure="true" max-connections="900">

   <ssl name="ssl" key-alias="1" password="changeit" certificate-key-file="/app/certs/mykeystore.jks" protocol="TLSv1" verify-client="false"/>

</connector>

Notice that the config has the keystore passwords stored in plaintext. Usually, this is not a good idea. Encrypted passwords are a topic of their own and out of scope for this tutorial. Anyone with access - legitimate or not - can read the config and password; compromising your keystore. The Vault Tool can be used to encrypt the keystore password that JBoss will use to access the keystore. Take a look at this article in the JBoss documentation: JBossAS7SecuringPasswords

Read More

Error Installing mysql-server-5.6 on Ubuntu 14.04 [FIX]

I was trying to install MySQL on one of my VMs late last night and the installation kept failing near the end (and at start up). Eventually, I realized that this system only has 256mb RAM (I have no shame) and that was resulting in the following failure:

start: Job failed to start  
invoke-rc.d: initscript mysql, action "start" failed.  
dpkg: error processing package mysql-server-5.6 (--configure):  
 subprocess installed post-installation script returned error exit status 1  
Setting up libhtml-template-perl (2.95-1) ...  
Setting up mysql-common-5.6 (5.6.16-1~exp1) ...  
Processing triggers for libc-bin (2.19-0ubuntu6) ...  
Processing triggers for ureadahead (0.100.0-16) ...  
Errors were encountered while processing:  
 mysql-server-5.6  
E: Sub-process /usr/bin/dpkg returned an error code (1)

There are a few solutions to working around the failure, this one is the fastest and easiest. No one really wants to hack around the config when they're rushing to get something installed.

I found a simple solution at AskUbuntu and the clever trick was:

On Ubuntu 14.04, I do the following to solve the problem:

Create a 4G swap file:

 sudo fallocate -l 4G /swapfile

Change its permission to only root could access and change:

 sudo chmod 600 /swapfile

Make it swap:

 sudo mkswap /swapfile

Activate:

 sudo swapon /swapfile




My VM failed at the step in red. The error:

 

swapon failed: Operation not permitted

But I'm root. What gives?

OpenVZ doesn't allow you to add swap. After all, you are paying by the amount of RAM made available to you. 

Then I came across this post at linux problem solver to create 'fake swap'.  This little script, will solve your MySQL installation failure. Just put the following into a file and name it fakeswap.sh:

 
#!/bin/bash 

SWAP="${1:-512}"

NEW="$[SWAP*1024]"; TEMP="${NEW//?/ }"; OLD="${TEMP:1}0"

umount /proc/meminfo 2> /dev/null

sed "/^Swap\(Total\|Free\):/s,$OLD,$NEW," /proc/meminfo > /etc/fake_meminfo

mount --bind /etc/fake_meminfo /proc/meminfo

free -m

Then:

 chmod +x fakeswap.sh

Though you don't actually get the swap, MySQL will pass its installation stage. If you're running this on Ubuntu which has bash as the default shell, you'll need to make sure that at step [root@server] sh fakeswap.sh (at the original link) you actually run:

 ./fakeswap.sh

Read More

A Beginner's Comprehensive Guide to Ubuntu Server Setup

• Sections covered in this guide:
• Background
• Best Practises
• Connecting to your server
• Hosts
• Hostname
• Timezone
• New User

Preamble, skip if you don't want to read any preliminary background information. The guide is designed not to just get you on your way with a server set up (as most other tutorials strive to do), it is also designed to help you understand why these things are being done. Before following this or any other guide, make sure you fully understand the commands you are about to run before running them or you may cause damage to your system. Some commands can be specially crafted and look innocent. In this guide, I will show you how to create a user account that should be used instead of root. Then we will give the account the capability to use sudo so we can run any commands that require elevated privileges.

*Extra information: Ubuntu, like many other Linux distributions, is designed as a multi-user system that is built around privileges. For example, certain users can be given the capability to run or access things that other users cannot - all in a hierarchical model. The 'root' account is the 'God' account. Be careful with this account. It is capable of wiping the drive of the system while the system is running, unlike Windows. We will avoid logging in as root and instead focus on elevating to 'root privileges' when we need to do something that requires more privileges than our standard account. Following this method helps prevent typing mistakes (if we read over what we wrote) and prevents people who have seen us type our log in use it for malicious tasks.*

There are only a few things in life that come easy. Installing software packages in Linux is one of them - usually. If you're new, you are probably under the impression that terror lies ahead in using the command-line. Luckily for you, common packages are installed from repositories, most of which your system is already configured to access.

So, what is a repository? Well, good question. Think of your server has a house within an ecosystem of resources, like a city. Your house is connected to 'repositories' like the supermarket, for food. It is connected to Costco for everything else. Common items, packages, are found in these repositories. The connection takes place by roads, which in our case here, is our SSH session. When you want a package, you can run a simple one-line command that will fetch it and install it on your system - like a phone call to Costco that leads to a delivery. There are many repositories, some enabled by default. In this case, Costco is one of the two.

Now that we know our server will  fetch packages, it's good to know something else you may not be aware of if you are coming from Windows. Installing something on your machine, such as Apache, will install a network of dependencies. Dependencies are little components, applications, or libraries required to make up the whole Apache install. Running an install command for a one could result in hundreds of dependencies that need to be installed to complete your request - such as installing the Gnome interface on a server (don't ever do that).

Repositories may store different versions of packages for different systems. Package managers are configured for the corresponding repository and the package manager is 'smart' enough to use what it needs. For example, some software is compiled for Ubuntu 12.04 32-bit and has separate compiled versions for 64-bit system (you'll likely see 'amd64' in the package name for these).

When you run the install command, the appropriate version should be selected for your system, unless you add a third-party repository or you specifically choose a version to install). It should be noted that 32-bit systems cannot install 64-bit packages but 64-bit can install 32-bit.

Enough preamble.


For the purpose of this tutorial, I'm going to assume you are using either a dedicated or virtual server and that you have root access to this system. The tutorial will also assume you are starting from a standard, fresh install of 12.04LTS, such as you would find from an Ubuntu.com download (Amazon's images may have some modifications).

First things first. There are some best practises you should understand before beginning your foray. On a server:

1. Use root only when you need root privileges (http://askubuntu.com/a/16179). Server admins are not vigilantes (well, not always) and should take this seriously. There will come a time that you agree.
2. Install only what you need to (the more you have running, the greater the attack vectors at an attacker's disposal. And they will find you)
3. Stick to an LTS release (Long Term Support - it will be supported longer and will therefore be more robust down the line)
4. Avoid new server releases for production machines if you need stability and security. Not that there's anything wrong with the integrity of the development team or their releases, but you should want to have a tested and patched system.
5. Avoid graphical interfaces (For one, you'll learn your server better if you interact with it through the CLI - command line interface. Secondly, tons of packages will need to be installed that you won't require and are arguably going to be your worst security decision. Thirdly, graphical interfaces are not optimized for servers. Fourth, most, if not all server tools will not have a graphical interface.)
6. You do not enter the '$' that is shown before each command. It is simply there to let you know you will be typing at the prompt.

Connecting to Your Server

If you are using Windows, you will need a tool such as PuTTY or KiTTY to connect to your server. If you are using Mac or Linux, you can use the built-in Terminal emulator and run a command to connect to the server. I am going to create the user 'john' and use johnghawi.com as the host (server address). You will need to use your own domain name or the server's IP address.

*For the first log in, you will likely need to use your root log in (user is root) unless an account was created for you. For commands, do not type the $ at the beginning.

Windows:

Protocol: SFTP/SSH
Username: root
Host: johnghawi.com
Port: 22

Linux/OSX:

$ ssh root@johnghawi.com

In the above command, we do not add the port because 22 is the default port. If you change your default ssh port to something like 50, you will need to specify it as shown below:

$ ssh -p 50 root@johnghawi.com

You will then be prompted for authentication to connect to your server. As this is your first time connecting to it from that system, accept it. The purpose of this notification is to make you aware of any man-in-the-middle attacks.

The next prompt will be for your password, enter it. You should be given a quick summary screen and a prompt waiting for a command. The next step is to patch the server with any updates. If you are logged in as root, you do not need to have 'sudo' in the command, but I will leave it in there for future reference.

$ sudo apt-get update
$ sudo apt-get upgrade

The first command updates those repositories I mentioned earlier. The next step applies necessary updates. The 'upgrade' command will not move you between server releases (12.04 to 13.04) unless you apply the -d switch. If you do not wish to have the patches applied directly, you can modify the second command by appending -y at the end (sudo apt-get upgrade -y).

This process may take some time depending on your server and the number of updates.

*TIP: You can concatenate two commands by adding && in-between. For example:

$ sudo apt-get update && sudo apt-get upgrade

*Note that you must add sudo before the second command (if not root). The importance of using the && operator is that if the first command fails for any reason (such as a spelling error), the second line will never run. Every concatenated command will only run if the command before it passes (or returns TRUE).

Hostname

Ubuntu reads the hostname from /etc/hostname file. You can find the system hostname by typing 'hostname' at the prompt.

$ hostname johnny

The above command will change the hostname to johnny until the next server reboot.

To change the hostname and have it persist across reboots, we need to edit the /etc/hostname file.

Since the file is in the /etc directory, we would need to elevate to superuser privileges if we are not currently logged in as root. If you are following this tutorial, you should still be logged in as root.

Check your current hostname:

$ hostname

*If you get an error, you likely do not have the 'net-tools' package installed. Run this command first:

$ apt-get install net-tools -y

Permanently changing your hostname is more useful. Do this by opening the /etc/hostname file in nano, a simple CLI text editor:

$ nano /etc/hostname

I would put johnghawi.com and you could put your domain. The hostname does not need to be a Fully Qualified Domain Name (FQDN) but it should be something unique. The hostname can be used to differentiate between servers using names like panther and tiger.

Ubuntu then uses /etc/init.d/hostname.sh to set the hostname at boot from  /etc/hostname. Essentially, Ubuntu will set the hostname at EACH boot time from the  /etc/hostname file using the hostname.sh script in /etc/init.d. If you are a little lost, simply follow the steps and do not worry much as this is a one-time setting we are making.

We can reboot the server or run the script for the hostname to take effect. Then type hostname to see that the new hostname from the /etc/hostname file has taken effect.

$ /etc/init.d/hostname.sh start

$ hostname

Getting to Know the HOSTS File

We now need to configure the /etc/hosts file. In the event that a DNS server is unavailable - or better yet, let's understand what happens when an application running on the server needs a path to another host. A DNS server typically acts as a dictionary look-up to that translates hostnames (johnghawi.com) to their corresponding IP addresses. But before our server looks to the DNS, it checks the /etc/hosts file to see if any resolutions are first defined there. Upon opening this file (you can use nano), you will notice two entries. 127.0.0.1 is set to localhost and 127.0.1.1 is set to Ubuntu. The latter was placed by Debian to support Gnome applications. If your system has a permanent IP, you can use that instead. Using a domain, you should add your domain and static IP, which is required for SSL.

If set by default in /etc/host.conf, the /etc/hosts file allows us to specify static addresses to be resolved, overriding DNS look-ups. It is important to note that addresses defined in the /etc/hosts file will cause your server to not bother querying BIND/DNS if it finds a relevant entry in the /etc/hosts file. Your server will do is query the /etc/hosts file to see if it should bother going to the DNS. If it finds the resolution in the /etc/hosts file, querying the DNS is skipped.

The /etc/hosts file will look very simple for our set up. Let's open the file:

$ nano /etc/hosts

The first thing that you might notice is the alignment of the headers does not align with the content:

IPAddress     Hostname    Alias                             
127.0.0.1          localhost              blog.johnghawi.com
74.125.142.121     blog.johnghawi.com     johnserver
74.125.142.121     webmail.johnghawi.com  johnserver
74.125.142.122     files.johnghawi.com    johnfiles

Let's take a minute to realize what the above table is telling us. At first, it may seem straight forward before it gets confusing. To keep things simple, you may find it easier to approach this table from right to left.

The Alias column on the right is a name for the server, useful when referencing locally on the network. In that case, johnserver maps to hostname blog.johnghawi.com and webmail.johnghawi.com and both resolve to the same IP Address. Next, johnfiles refers to the files.johnghawi.com hostname, which may just be accessible through another of the same server's interface.

Configure your server according to the table above. More than likely, if you are following this tutorial you may only need the first two lines, with the second one being just your domain and no subdomain.

The last step is to either restart your server or the service itself using:

$ /etc/rc.d/init.d/network restart

Timezone

It is a good idea to set the timezone of the system. You may wish to either use the local timezone or the timezone of the majority of your users. The correct timezone may be useful for reading logs.

$ dpkg-reconfigure tzdata

New User

As promised, we will add a new user to the server. We will have two accounts enabled on the system, calling the second user 'john'. The 'root' account (full privileges) and the 'john' account (limited privileges). When using the command line, let's say as the user we're about to create, john, you can switch to another user that exists on the system, such as 'alice' by running $ su alice and entering Alice's password. The su command stands for Substitute User. Alternatively, John does not have to switch Alice's account, he can elevate by using the sudo command (SuperUser Do), which allows john to execute commands given his elevated security clearance, if granted. John will use his own password to elevate. . Let's create 'john':

$ adduser john

Answer the lines accordingly and press enter to use the default, if presented with any. The next step is critical. Its purpose is to give our 'john' account the privilege to elevate by using the 'sudo' command (as you may have seen above). Type $ man usermod to learn what each switch does. Remember, commands are case sensitive; -g != -G.

$ usermod -a -G sudo john

Now we test to make sure we can log in as 'john'. Log out with $ logout or reboot with $ reboot

Use the instructions above to log in using the account name you just created. Type $ sudo nano at the prompt, enter your password, and see if nano opens.  If successful, your new account is set up and has sudo capability. You should start using the new account by default.

Congratulations, your new server is successfully set up! I will be adding Part 2 and linking to it from this article in a week or so outlining steps to harden your server from common attacks.

Read More

An Introduction to Users and Groups in Ubuntu

Disclaimer

This is a post you should read fully and understand before blindly following any commands as you can easily strip superuser access if you do not understand what you are doing. In fact, I recommend researching these topics outside of this post to get a better grasp of this area. You can learn more about any command by adding 'man' before it at the terminal. At the very least, ask questions!

Let's Begin

A UID is an entity that can possess ownership of files. A user is a human-readable format for a user id.

Users can belong to more than one supplementary group but each user must belong to one (and only one) primary group.

A group can have many users and group membership provides privileges to shares and resources to users of that group.

To add the user john:

 
$ sudo adduser john

Along with creating the user 'john', the group 'john' will be created as well.

To create the user john and place in the existing group teachers without creating the 'john' group, run:

 
$ sudo adduser john --ingroup teachers

To change a user's primary group, run the command:

 
$ sudo usermod -g group user

You can add the user john to the supplementary groups student and employee with:

 
$ sudo usermod -a -G student,employee john

Note: It is important to pay attention to two things. The -G switch is capital and there is no whitespace between group names. The command line interface (CLI) is very specific to capitalization and format so take care to always be precise.

Running the command without the -a switch will remove the user from any other groups. The -a switch allows you to retain the user's existing groups. Example: without -a, if the user was a member of the group 'teacher' before running the command, he will be removed from the teacher group after the command has successfully executed. That will be the case by running the command that changes the user's primary group. The problem is, if this is your user, you can strip away your superuser rights with that command, so make sure you test this on a non-production system first.

Check your users and ids

You can run $ id to print the logged in user's id and group membership on the screen. Optionally, you can specify which user to print by adding that user as a second argument to the id command.

Running id on my system, I get:

 
john@flare:~$ id
uid=1000(john) gid=1000(john) groups=1000(john),4(adm),27(sudo),30(dip),46(plugdev),118(lpadmin)

Let's understand the information we were returned:
uid=1000(john)
gid=1000(john)
groups=1000(john),4(adm),27(sudo),30(dip)....

My username is john and my userid is 1000. The primary group (gid) that I belong to is also known as john. My user also belongs to the secondary groups: adm, sudo, dip, and so on.

But what are the numbers beside the secondary groups? 
I'm glad you asked. The numbers are reserved id spaces. I use Ubuntu on my laptop. Ubuntu starts human user ids at 1000 (some other distros start at 500). The underlying idea is to give services enough id space to choose their own unique id without interfering with human user ids.

To take a more in-depth look at the users and their information on your system, head to the terminal and type (exit with CTRL+X):
$ nano /etc/passwd
$ nano /etc/group

Each is a text file on your system that your operating system uses to store a list of users and groups. In the group file, you may see your username appended to some of the lines, letting you know the user is a member of that group. In the passwd file, you'll see the username, userid, user's primary group, and the user's home directory.

For more information

To learn more about the command you wish to use (such as usermod), enter man usermod at the terminal to get the manual. If you are using an elevated (such as root) user, you can omit 'sudo' from the commands.

Coming up next: chmod and chown

Read More

Disabling IPv6 on Ubuntu Server 12.04

A few months ago, I was sad to learn that Fail2Ban does not protect against IPv6 traffic. If your web traffic only operates on IPv4, then you have nothing to worry about. That is, unless you have the IPv6 stack enabled and don't need it.

Luckily, I came across a great little post from webupd8.org that I've summarized below (should the post ever be removed). In either case, this post is for anyone wishing to disable IPv6 on their Ubuntu server.

1. Check if the IPv6 stack is enabled. The stack is enabled if the return is 0.

$ cat /proc/sys/net/ipv6/conf/all/disable_ipv6

2. Elevate to root and open your /etc/sysctl.conf file in nano.

$ sudo nano /etc/sysctl.conf

3. Paste the following at the end of the sysctl.conf:

#disable ipv6
net.ipv6.conf.all.disable_ipv6 = 1    
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1     

4. Reboot and perform step 1. If you find the return to still be 0, head over to the webupd8 link above to see the other methods they have listed.

Read More