How to Configure Your Dev Machine to Work From Anywhere (Part 3)

In the previous articles, I talked about my mobile setup and how I’m able to continue working on the go. In this final installment, I’ll talk about how to securely install and configure the software I’m using. 

In the previous articles, I talked about my mobile setup and how I’m able to continue working on the go. In this final installment, I’ll talk about how to install and configure the software I’m using. Most of what I’m talking about here is on the server side, because the Android and iPhone apps are pretty straightforward to configure.

Before we begin, however, I want to mention that this setup I’ve been describing really isn’t for production machines. This should only be limited to development and test machines. Also, there are many different ways to work remotely, and this is only one possibility. In general, you really can’t beat a good command-line tool and SSH access. But in some cases, that didn’t really work for me. I needed more; I needed a full Chrome JavaScript debugger, and I needed better word processing than was available on my Android tablets.

Here, then, is how I configured the software. Note, however, that I’m not writing this as a complete tutorial, simply because that would take too much space. Instead, I’m providing overviews, and assuming you know the basics and can google to find the details. We’ll take this step by step.

Spin up your server

First, we spin up the server on a host. There are several hosting companies; I’ve used Amazon Web Services, Rackspace, and DigitalOcean. My own personal preference for the operating system is Ubuntu Linux with LXDE. LXDE is a full desktop environment that includes the OpenBox window manager. I personally like OpenBox because of its simplicity while maintaining visual appeal. And LXDE is nice because, as its name suggests (Lightweight X11 Desktop Environment), it’s lightweight. However, many different environments and window managers will work. (I tried a couple tiling window managers such as i3, and those worked pretty well too.)

The usual order of installation goes like this: You use the hosting company’s website to spin up the server, and you provide a key file that will be used for logging into the server. You can usually use your own key that you generate, or have the service generate a key for you, in which case you download the key and save it. Typically when you provide a key, the server will automatically be configured to log in only using SSH with the key file. However, if not, you’ll want to follow disable password logins.

Connect to the server

The next step is to actually log into the server through an SSH command line and first set up a user for yourself that isn’t root, and then set up the desktop environment. You can log in from your desktop Linux, but if you like, this is a good chance to try out logging in from an Android or iOS tablet. I use JuiceSSH; a lot of people like ConnectBot. And there are others. But whichever you get, make sure it allows you to log in using a key file. (Key files can be created with or without a password. Also make sure the app you use allows you to use whichever key file type you created–password or no password.)

Copy your key file to your tablet. The best way is to connect the tablet to your computer, and transfer the file. However, if you want a quick and easy way to do it, you can email it. But be aware that you’re sending the private key file through an email system that other people could potentially access. It’s your call whether you want to do that. Either way, get the file installed on the tablet, and then configure the SSH app to log in using the key file, using the app’s instructions.

Then using the app, connect to your server. You’ll need the username, even though you’re using a key file (the server needs to know who you’re logging in as with the key file, after all); AWS typically uses “ubuntu” for the username for Ubuntu installations; others simply give you the root user. For AWS, to do the installation you’ll need to type sudo before each command since you’re not logged in as root, but won’t be asked for a password when running sudo. On other cloud hosts you can run the commands without sudo since you’re logged in as root.

Oh and by the way, because we don’t yet have a desktop environment, you’ll be typing commands to install the software. If you’re not familiar with the package installation tools, now is a chance to learn about them. For Debian-based systems (including Ubuntu), you’ll use apt-get. Other systems use yum, which is a command-line interface to the RPM package manager.

Install LXDE

From the command-line, it’s time to set up LXDE, or whichever desktop you prefer. One thing to bear in mind is that while you can run something big like Cinnamon, ask yourself if you really need it. Cinnamon is big and cumbersome. I use it on my desktop, but not on my hosted servers, opting instead for more lightweight desktops like LXDE. And if you’re familiar with desktops such as Cinnamon, LXDE will feel very similar.

There are lots of instructions online for installing LXDE or other desktops, and so I won’t reiterate the details here. DigitalOcean has a fantastic blog with instructions for installing a similar desktop, XFCE.

Install a VNC server

Then you need to install a VNC server. Instead of using TightVNC, which a lot of people suggest, I recommend vnc4server because it allows for easy resolution changes, as I’ll describe shortly.

While setting up the VNC server, you’ll create a VNC username. You can just use a username and password for VNC, and from there you’re able to connect from a VNC client app to the system. However, the connection won’t be secure. Instead, you’ll want to connect through what’s called an SSH tunnel. The SSH tunnel is basically an SSH session into the server that is used for passing connections that would otherwise go directly over the internet.

When you connect to a server over the Internet, you use a protocol and a port. VNC usually uses 5900 or 5901 for the port. But with an SSH tunnel, the SSH app listens on a port on the same local device, such as 5900 or 5901. Then the VNC app, instead of connecting to the remote server, connects locally to the SSH app. The SSH app, in turn, passes all the data on to the remote system. So the SSH serves as a go-between. But because it’s SSH, all the data is secure.

So the key is setting up a tunnel on your tablet. Some VNC apps can create the tunnel; others can’t and you need to use a separate app. JuiceSSH can create a tunnel, which you can use from other apps. My preferred VNC app, Remotix, on the other hand, can do the tunnel itself for you. It’s your choice how you do it, but you’ll want to set it up.

The app will have instructions for the tunnel. In the case of JuiceSSH, you specify the server you’re connecting to and the port, such as 5900 or 5901. Then you also specify the local port number the tunnel will be listening on. You can use any available port, but I’ll usually use the same port as the remote one. If I’m connecting to 5901 on the remote, I’ll have JuiceSSH also listen on 5901. That makes it easier to keep straight. Then you’ll open up your VNC app, and instead of connecting to a remote server, you connect to the port on the same tablet. For the server you just use 127.0.0.1, which is the IP address of the device itself. So to re-iterate:

  1. JuiceSSH connects, for example, to 5901 on the remote host. Meanwhile, it opens up 5901 on the local device.
  2. The VNC app connects to 5901 on the local device. It doesn’t need to know anything about what remote server it’s connecting to.

But some VNC apps don’t need another app to do the tunneling, and instead provide the tunnel themselves. Remotix can do this; if you set up your app to do so, make sure you understand that you’re still tunneling. You provide the information needed for the SSH tunnel, including the key file and username. Then Remotix does the rest for you.

Once you get the VNC app going, you’ll be in. You should see a desktop open with the LXDE logo in the background. Next, you’ll want to go ahead and configure the VNC client to your liking; I prefer to control the mouse using drags that simulate a trackpad; other people like to control the mouse by tapping exactly where you want to click. Remotix and several other apps let you choose either configuration.

Configuring the Desktop

Now let’s configure the desktop. One issue I had was getting the desktop to look good on my 10-inch tablet. This involved configuring the look and feel by clicking the taskbar menu < Preferences < Customize Look and Feel (or run from the command line lxappearance).

lxappearance

I also used OpenBox’s own configuration tool by clicking the taskbar menu < Preferences < OpenBox Configuration Manager (or runobconf).

obconf

My larger tablet’s screen isn’t huge at 10 inches, so I configured the menu bars and buttons and such to be somewhat large for a comfortable view. One issue is the tablet has such a high resolution that if I used the maximum resolution, everything was tiny. As such, I needed to be able to change resolutions based on the work I was doing, as well as based on which tablet I was using. This involved configuring the VNC server, though, not LXDE and OpenBox. So let’s look at that.

In order to change resolution on the fly, you need a program that can manage the RandR extensions, such as xrandr. But the TightVNC server that seems popular doesn’t work with RandR. Instead, I found the vvnc4server program works with xrandr, which is why I recommend using it instead. When you configure vnc4server, you’ll want to provide the different resolutions in the command’s -geometry option. Here’s an init.d service configuration file that does just that. (I modified this based on one I found on DigitalOcean’s blog.)

#!/bin/bash
PATH="$PATH:/usr/bin/"
export USER="jeff"
OPTIONS="-depth 16 -geometry 1920x1125 -geometry 1240x1920 -geometry 2560x1500 -geometry 1920x1080 -geometry 1774x1040 -geometry 1440x843 -geometry 1280x1120 -geometry 1280x1024 -geometry 1280x750 -geometry 1200x1100 -geometry 1024x768 -geometry 800x600 :1"
. /lib/lsb/init-functions
case "$1" in
start)
log_action_begin_msg "Starting vncserver for user '${USER}' on localhost:${DISPLAY}"
su ${USER} -c "/usr/bin/vnc4server ${OPTIONS}"
;;
stop)
log_action_begin_msg "Stoping vncserver for user '${USER}' on localhost:${DISPLAY}"
su ${USER} -c "/usr/bin/vnc4server -kill :1"
;;
restart)
$0 stop
$0 start
;;
esac
exit 0

The key here is the OPTIONS line with all the -geometry options. These will show up when you run xrandr from the command line:

xrandr.png

You can use your VNC login to modify the file in the init.d directory (and indeed I did, using the editor called scite). But then after making these changes, you’ll need to restart the VNC service just this one time, since you’re changing its service settings. Doing so will end your current VNC session, and it might not restart correctly. So you might need to log in through JuiceSSH to restart the VNC server. Then you can log back in with the VNC server. (You also might need to restart the SSH tunnel.) After you do, you’ll be able to configure the resolution. And from then on, you can change the resolution on the fly without restarting the VNC server.

To change resolutions without having to restart the VNC server, just type:

xrandr -s 1

Replace 1 with the number for the resolution you want. This way you can change the resolution without restarting the VNC server.

Server Concerns

After everything is configured, you’re free to use the software you’re familiar with. The only catch is that hosts charge a good bit for servers that have plenty of RAM and disk space. As such, you might be limited on what you can run based on the amount of RAM and cores. Still, I’ve found that with just 2GB of RAM and 2 cores, with Ubuntu and LXDE, I’m able to have open Chrome with a few pages, LibreOffice with a couple documents open, Geany for my code editing, and my own server software running under node.js for testing, and mysql server. Occasionally if I get too many Chrome tabs open, the system will suddenly slow way down and I have to shut down tabs to free up more memory. Sometimes I run MySQL Workbench and it can bog things down a bit too, but it isn’t bad if I close up LibreOffice and leave only one or two Chrome tabs open. But in general, for most of my work, I have no problems at all.

And on top of that, if I do need more horsepower, I can spin up a bigger server with 4GB or 8GB and four cores or eight cores. But that gets costly and so I don’t do it for too many hours.

Multiple Screens

For fun, I did manage to get two screens going on a single desktop, one on my bigger 10-inch ASUS transformer tablet, and one on my smaller Nexus 7 all from my Linux server running on a public cloud host, complete with a single mouse moving between the two screens. To accomplish this, I started two VNC sessions, one from each tablet, and then from the one with the mouse and keyboard, I ran:

x2x -east -to :1

This basically connected the single mouse and keyboard to both displays. It was a fun experiment, but in my case, provided little practical value because it wasn’t like a true dual-display on a desktop computer. I couldn’t move slide windows between the displays, and the Chrome browser won’t open under more than one X display. In my case, for web development, I wanted to be able to open up the Chrome browser on one tablet, and then the Chrome JavaScript debug window on the other, but that didn’t work out.

Instead, what I found more useful was to have an SSH command-line shell on the smaller tablet, and that’s where I would run my node.js server code, which was printing out debug information. Then on the other I would have the browser running. That way I can glance back and forth without switching between windows on the single VNC login on the bigger tablet.

Back to Security

I can’t understate the importance of making sure you have your security set up and that you understand how the security works and what the ramifications are. I highly recommend using SSH with a keyfile login only, and no password logins allowed. And treat this as a development or test machine; don’t put customer data on the machine that could open you up to lawsuits in the event the machine gets compromised.

Instead, for production machines, allocate your production servers using all the best practices laid out by your own IT department security rules, and the host’s own rules. One issue I hit is my development machine needs to log into git, which requires a private key. My development machine is hosted, which means that private key is stored on a hosted server. That may or may not be a good idea in your case; you and your team will need to decide whether to do it. In my case, I decided I could afford the risk because the code I’m accessing is mostly open-source and there’s little private intellectual property involved. So if somebody broke into my development machine, they would have access to the source code for a small but non-vital project I’m working on, and drafts of these articles–no private or intellectual data.

Web Developers and A Pesky Thing Called Windows

Before I wrap this up, I want to present a topic for discussion. Over the past few years I’ve noticed that a lot of individual web developers use a setup quite similar to what I’m describing. In a lot of cases they use Windows instead of Linux, but the idea is the same regardless of operating system. But where they differ from what I’m describing is they host their entire customer websites and customer data on that one machine, and there is no tunneling; instead, they just type in a password. That is not what I’m advocating here. If you are doing this, please reconsider. (I personally know at least three private web developers who do this.)

Regardless of operating systems, take some time to understand the ramifications here. First, by logging in with a full desktop environment, you’re possibly slowing down your machine for your dev work. And if you mess something up and have to reboot, during that time your clients’ websites aren’t available during that time. Are you using replication? Are you using private networking? Are you running MySQL or some other database on the same machine instead of using virtual private networking? Entire books could (and have been) written on such topics and what the best practices are. Learn about replication; learn about virtual private networking and how to shield your database servers from outside traffic; and so on. And most importantly consider the security issues. Are you hosting customer data in a site that could easily be compromised? That could spell L-A-W-S-U-I-T. And that brings me to my conclusion for this series.

Concluding Remarks

Some commenters on the previous articles have brought up some valid points; one even used the phrase “playing.” While I really am doing development work, I’m definitely not doing this on production machines. If I were, that would indeed be playing and not be a legitimate use for a production machine. Use SSH for the production machines, and pick an editor to use and learn it. (I like vim, personally.) And keep the customer data on a server that is accessible only from a virtual private network. Read this to learn more.

Learn how to set up and configure SSH. And if you don’t understand all this, then please, practice and learn it. There are a million web sites out there to teach this stuff, including linux.com. But if you do understand and can minimize the risk, then, you really can get some work done from nearly anywhere. My work has become far more productive. If I want to run to a coffee shop and do some work, I can, without having to take a laptop along. Times are good! Learn the rules, follow the best practices, and be productive.

See the previous tutorials:

How to Set Up Your Linux Dev Station to Work From Anywhere

Choosing Software to Work Remotely from Your Linux Dev Station

Source: LinuxLearn

Build Your Own Linux Distro

Linux Voice: Do you have a favourite distro that you’ve spent hours customising? Mayank Sharma shows you how you can spin it into a live distro that you can pass to friends, family, or even on to DistroWatch!

There are hundreds of actively maintained Linux distributions. They come in all shapes, sizes and configurations. Yet there’s none like the one you’re currently running on your computer. That’s because you’ve probably customised it to the hilt – you’ve spent numerous hours adding and removing apps and tweaking aspects of the distro to suit your workflow.

Wouldn’t it be great if you could convert your perfectly set up system into a live distro? You could carry it with you on a flash drive or even install it on other computers you use.

 

Read more at LinuxVoice.

Source: LinuxLearn

Five Important Steps Linux Job Seekers Should Take

Linux talent is in demand, and organizations are willing to pay a lot for those with the right qualifications. Here are tips for the Linux job seeker.

Linux talent is in demand, and organizations are willing to pay a lot for those with the right qualifications. Here are tips for the Linux job seeker.

Read more at eWeek

Source: LinuxLearn

How to Install a Debian 7 (Wheezy) Minimal Server

This tutorial shows how to install a Debian 7 (Wheezy) minimal server. The purpose of this guide is to provide a minimal Debian setup that can be used as basis for our other tutorials here at howtoforge.

This tutorial shows how to install a Debian 7 (Wheezy) minimal server. The purpose of this guide is to provide a minimal Debian setup that can be used as basis for our other tutorials here at howtoforge.

Read more at HowtoForge

Source: LinuxLearn

How to Install and Configure ‘Collectd’ and ‘Collectd-Web’ to Monitor Server Resources in Linux

Collectd-web is a web front-end monitoring tool based on RRDtool (Round-Robin Database Tool), which interprets and graphical outputs the data collected by the Collectd service on Linux systems. Collectd service comes by default with… 

Collectd-web is a web front-end monitoring tool based on RRDtool (Round-Robin Database Tool), which interprets and graphical outputs the data collected by the Collectd service on Linux systems. Collectd service comes by default with…

Read more at TecMint

Source: LinuxLearn

How to Make Linux's Desktop Look Good on High-Resolution Displays

If you’re running GNOME 3 in Linux, your first boot will have you looking for your reading glasses. (Windows suffers from similar issues with high-DPI displays.)

Ultra-high-resolution displays with high pixel densities are all the rage now, and for good reason: They look amazing compared to conventional displays. The big problem for PC users is that a lot of software isn’t designed with that level of pixel density in mind.

If you’re running GNOME 3 in Linux, your first boot will have you looking for your reading glasses. (Windows suffers from similar issues with high-DPI displays.)

Read more at PCWorld.

Source: LinuxLearn

Automation is the Key to the Cloud

“You can’t work in IT without at least some knowledge of Linux. It is a foundational knowledge that is just expected of new hires,” says James Schweitzer, an IT specialist working in the IBM Watson Solutions Division.

An understanding of IT’s past is important to moving forward with the cloud. When James Schweitzer, an IT specialist working in the IBM Watson Solutions Division, looks back on how the work of Ada Lovelace and Charles Babbage changed computing, he can’t help but get excited about Watson’s potential.

read more

Read more at OpenSource.com

Source: LinuxLearn

How to Find Your Linux Version or Distro Release, and Why It Matters

Quick quiz: How do you know which version of Linux you are using? Which kernel? Which distribution? Which release of your distribution?

kernel release version

Quick quiz: How do you know which version of Linux you are using? Which kernel? Which distribution? Which release of your distribution?

Believe it or not, there are situations where this information could be of great importance. Say, for example, a new threat has been released (such as a rather serious OpenSSL-related security issue) which only affects specific releases. If the flaw only affects specific distributions, distribution releases, kernels, or packages you need to be able to quickly gather information about the distro you’re running, and act.

Outside of that very crucial example, there are other reasons why you will want to know about Linux releases—even release types—in order to better navigate the world of Linux and all the power that comes with the platform.

Before we get into how to discern the various bits of information on your desktops and servers, I want to discuss the two major types of Linux releases.

Rolling versus fixed release

There are, effectively, two types of releases in the world of Linux:

  • Rolling

  • Fixed.

The two different releases are quite different, so it is important to understand how they work. The easiest way to know the difference between a Rolling and Fixed released distribution is this:

A Rolling release is constantly being updated and works with one code branch.

There are two ways of dealing with this constant state of updating. The first, and most popular, is to release a steady stream of very small updates. With this release model, the distribution is in a perpetual state of having the most up-to-date software. The second method (one which Ubuntu Core is adopting) is to replace the full image of the operating system with a new one as it is made available. Clearly, the latter option is only viable for cloud deployments (as replacing a full image is really just a distribution upgrade or reinstallation).

The Fixed release is fairly standard. You install a release and, as long as said release is supported, security and patch updates to packages will be available to you as they are seeded to the distribution repositories. You may not see updates daily (or even weekly), but they will eventually appear as available to your desktop or server. The upside of the Fixed release is stability. For many, the major downfall of the Fixed release is the need to completely reinstall (or trust that a major upgrade will not have issues on a production machine) based on a distribution’s release schedule (such as Ubuntu’s six-month schedule).

Each release type has its pros and cons. For example, the Rolling release offers you a platform that almost always has the most up-to-date version of the software you use, but due to that bleeding edge nature, may suffer instability at times. The Fixed release most often will include software that is less than bleeding edge, but it may often enjoy a bit more stability.

For a full list of Rolling release Linux distributions, check out this Wiki page.

With that information out of the way, how do you “uncover” the necessary information about your particular Linux distribution? There are a few tools at your fingertips. Let’s use them.

It is also important to make mention of a particular release structure given to Ubuntu and its supported flavors (Kubuntu, Xubuntu, Ubuntu GNOME, etc). Every two major releases (i.e. 12.04, 14.04, 16.04, etc.) an Ubuntu release is considered Long Term Support. This means support for the release will extend for five years (on both desktops and servers). On standard, non-LTS releases, support is only valid for six months. An LTS release is Enterprise-focused, compatible with new hardware, and more thoroughly tested than non-LTS releases. With that said, if you want a more cutting-edge Ubuntu distribution, go with the non-LTS release. If you want stability and support, install only the LTS releases.

Finding your kernel release

There will be times when you must know your kernel release number. Fortunately, the developers saw fit to include a handy tool that will quickly display your kernel release number. Here’s what you need to do:

  1. Open up a terminal window

  2. Issue the command

    uname -r
  3. Take note of the information displayed (Figure 1).

Finding your distribution release

There may be times when you need to know the release number you currently use. Again, there’s a handy command to find that information. Do the following:

  1. Open a terminal window

  2. Issue the command

    lsb_release -a
  3. Take note of the information displayed (Figure 2).

distro release number

If your command fu isn’t what it should be, most distributions display their release numbers in Settings > Details > Overview (Figure 3).

Figure 3: The Ubuntu release number as seen from the Settings tool.

This method of discerning your distribution release information has the added bonus of handing you some details about your system hardware (memory, CPU, graphics, OS type, and disk size).

Finding a specific package release number

Let’s dig a bit deeper. Say you’ve read that OpenSSL has a security flaw that affects only specific releases. How do you find out which version of OpenSSL is on your system? This will depend upon your distribution.

For a Debian-based distribution (such as Ubuntu), you would issue the command:

dpkg -l openssl

Which would report all the information you needed for the package installed on your system. (Figure 4).

OpenSSL version info

If you’re using an rpm-based distribution (such as Fedora), the command to locate information about OpenSSL would be:

rpm -qa | grep openssl

The above command will return information on all installed openssl packages.

Figure 5: Details on OpenSSL installed on Fedora 22.

You now have the knowledge and tools to find your release information. You may never need to know any of this data … but on the occasion that you do, you’ll be glad it’s at your fingertips. It is of the utmost importance that, when you hear of critical issues surrounding packages like OpenSSL, SSH, PHP, etc. you check the versions installed on your machine against the affected packages and take action. Luckily, you now have the ability to do just that.

Source: LinuxLearn

How to Run Your Own Git Server

GitHub is a great service, however there are some limitations and restrictions, especially if you are an individual or a small player. In cases like these or when you want more control, the best path is to run Git on your own server.

Manage your code on your own server by running a bare, basic Git server or via the GitLab GUI tool.

This month we are celebrating the anniversary of Git, a versioning system developed by Linus Torvalds. Git is being used by millions of users around the globe; crossing borders and boundaries.

There are companies like GitHub which are now offering code hosting services based on Git. According to reports, GitHub, a code hosting site, is the world’s largest code hosting service. The company claims that there are 9.2M people collaborating right now across 21.8M repositories on GitHub. Big companies are now moving to GitHub. Even Google, the search engine giant, is shutting it’s own Google Code and moving to GitHub.

Run your own Git server

GitHub is a great service, however there are some limitations and restrictions, especially if you are an individual or a small player. One of the limitations of GitHub is that the free service doesn’t allow private hosting of the code. You have to pay a monthly fee of $7 to host 5 private repositories, and the expenses go up with more repos.

In cases like these or when you want more control, the best path is to run Git on your own server. Not only do you save costs, you also have more control over your server. In most cases a majority of advanced Linux users already have their own servers and pushing Git on those servers is like ‘free as in beer’.

In this tutorial we are going to talk about two methods of managing your code on your own server. One is running a bare, basic Git server and and the second one is via a GUI tool called GitLab. For this tutorial I used a fully patched Ubuntu 14.04 LTS server running on a VPS.

Install Git on your server

In this tutorial we are considering a use-case where we have a remote server and a local server and we will work between these machines. For the sake of simplicity we will call them remote-server and local-server.

First, install Git on both machines. You can install Git from the packages already available via the repos or your distros, or you can do it manually. In this article we will use the simpler method:

sudo apt-get install git-core

Then add a user for Git.

sudo useradd git
passwd git

In order to ease access to the server let’s set-up a password-less ssh login. First create ssh keys on your local machine:

ssh-keygen -t rsa

It will ask you to provide the location for storing the key, just hit Enter to use the default location. The second question will be to provide it with a pass phrase which will be needed to access the remote server. It generates two keys – a public key and a private key. Note down the location of the public key which you will need in the next step.

Now you have to copy these keys to the server so that the two machines can talk to each other. Run the following command on your local machine:

cat ~/.ssh/id_rsa.pub | ssh git@remote-server "mkdir -p ~/.ssh && cat >>  ~/.ssh/authorized_keys"

Now ssh into the server and create a project directory for Git. You can use the desired path for the repo.

git@server:~ $ mkdir -p /home/swapnil/project-1.git

Then change to this directory:

cd /home/swapnil/project-1.git

Then create an empty repo:

git init --bare
Initialized empty Git repository in /home/swapnil/project-1.git

We now need to create a Git repo on the local machine.

mkdir -p /home/swapnil/git/project

And change to this directory:

cd /home/swapnil/git/project

Now create the files that you need for the project in this directory. Stay in this directory and initiate git:

git init 
Initialized empty Git repository in /home/swapnil/git/project

Now add files to the repo:

git add .

Now every time you add a file or make changes you have to run the add command above. You also need to write a commit message with every change in a file. The commit message basically tells what changes were made.

git commit -m "message" -a
[master (root-commit) 57331ee] message
 2 files changed, 2 insertions(+)
 create mode 100644 GoT.txt
 create mode 100644 writing.txt

In this case I had a file called GoT (Game of Thrones review) and I made some changes, so when I ran the command it specified that changes were made to the file. In the above command ‘-a’ option means commits for all files in the repo. If you made changes to only one you can specify the name of that file instead of using ‘-a’.

An example:

git commit -m "message" GoT.txt
[master e517b10] message
 1 file changed, 1 insertion(+)

Until now we have been working on the local server. Now we have to push these changes to the server so the work is accessible over the Internet and you can collaborate with other team members.

git remote add origin ssh://git@remote-server/repo-<wbr< a="">>path-on-server..git

Now you can push or pull changes between the server and local machine using the ‘push’ or ‘pull’ option:

git push origin master

If there are other team members who want to work with the project they need to clone the repo on the server to their local machine:

git clone git@remote-server:/home/swapnil/project.git

Here /home/swapnil/project.git is the project path on the remote server, exchange the values for your own server.

Then change directory on the local machine (exchange project with the name of project on your server):

cd /project

Now they can edit files, write commit change messages and then push them to the server:

git commit -m 'corrections in GoT.txt story' -a
And then push changes:
git push origin master

I assume this is enough for a new user to get started with Git on their own servers. If you are looking for some GUI tools to manage changes on local machines, you can use GUI tools such as QGit or GitK for Linux.

QGit

Using GitLab

This was a pure command line solution for project owner and collaborator. It’s certainly not as easy as using GitHub. Unfortunately, while GitHub is the world’s largest code hosting service; its own software is not available for others to use. It’s not open source so you can’t grab the source code and compile your own GitHub. Unlike WordPress or Drupal you can’t download GitHub and run it on your own servers.

As usual in the open source world there is no end to the options. GitLab is a nifty project which does exactly that. It’s an open source project which allows users to run a project management system similar to GitHub on their own servers.

You can use GitLab to run a service similar to GitHub for your team members or your company. You can use GitLab to work on private projects before releasing them for public contributions.

GitLab employs the traditional Open Source business model. They have two products: free of cost open source software, which users can install on their own servers, and a hosted service similar to GitHub.

The downloadable version has two editions – the free of cost community edition and the paid enterprise edition. The enterprise edition is based on the community edition but comes with additional features targeted at enterprise customers. It’s more or less similar to what WordPress.org or WordPress.com offer.

The community edition is highly scalable and can support 25,000 users on a single server or cluster. Some of the features of GitLab include: Git repository management, code reviews, issue tracking, activity feeds, and wikis. It comes with GitLab CI for continuous integration and delivery.

Many VPS providers such as Digital Ocean offer GitLab droplets for users. If you want to run it on your own server, you can install it manually. GitLab offers an Omnibus package for different operating systems. Before we install GitLab, you may want to configure an SMTP email server so that GitLab can push emails as and when needed. They recommend Postfix. So, install Postfix on your server:

sudo apt-get install postfix

During installation of Postfix it will ask you some questions; don’t skip them. If you did miss it you can always re-configure it using this command:

sudo dpkg-reconfigure postfix

When you run this command choose “Internet Site” and provide the email ID for the domain which will be used by Gitlab.

In my case I provided it with:

swapnil@mysite.com

Use Tab and create a username for postfix. The Next page will ask you to provide a destination for mail.

In the rest of the steps, use the default options. Once Postfix is installed and configured, let’s move on to install GitLab.

Download the packages using wget (replace the download link with the latest packages from here) :

wget https://downloads-packages.s3.amazonaws.com/ubuntu-14.04/gitlab_7.9.4-omnibus.1-1_amd64.deb

Then install the package:

sudo dpkg -i gitlab_7.9.4-omnibus.1-1_amd64.deb

Now it’s time to configure and start GitLabs.

sudo gitlab-ctl reconfigure

You now need to configure the domain name in the configuration file so you can access GitLab. Open the file.

nano /etc/gitlab/gitlab.rb

In this file edit the ‘external_url’ and give the server domain. Save the file and then open the newly created GitLab site from a web browser.

GitLab 1

By default it creates ‘root’ as the system admin and uses ‘5iveL!fe’ as the password. Log into the GitLab site and then change the password.

GitLab 2

Once the password is changed, log into the site and start managing your project.

GitLab manage project page

GitLab is overflowing with features and options. I will borrow popular lines from the movie, The Matrix: “Unfortunately, no one can be told what all GitLab can do. You have to try it for yourself.”

Source: LinuxLearn