Git Flow Config for Source Tree with git

GitFlow

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
Effectively you will have the following branches:

1 – master

This is where all your live code should live.

2 – dev

This is where all your code in development will be merged to from their hotfixes, features and releases (the gitflow branches).

3 – hotfix/

This is where your fixes for live code live, this is when you find a bug and want to quickly fix it without creating a whole new feature and release.

4 – feature/

This is where your new feature live whilst they are in dev. Your feature when finished will be merged into the dev branch only and not master

5 – release/

When you have finished building a feature, or a batch of features and want to release them a release branch is created. All the features are testing together, then the release branch when everyone is happy with it is merged into dev AND master.

 Setting up gitconfig in source tree for gitflow

Step1 –

Create an account in gitHub and create a repositoryStep2 – Install sourcetree

Step3 –

When you open sourcetree sign in with your github credentials

Step4 –

You should be able to pick your repository from github

Step5 –

Once there, create a new branch called “dev” from master and commit to origin

Step6 –

You should effectively have two branches now, master and dev.

Step7 –

Now go to the repository menu and select repository settings, then choose edit config file…

Step8 –

Copy the following config file into it, save and thats it:

Using gitflow: Scenario:  Bug found on your live website.

Step1:

Ensure all branches are up to date (ie pull all). Click the gitflow button in source tree and choose new “start new hotfix”.

Step2:

This will auto create a new branch with the name of your hotfix (only numbers, underscores and letters)

Step3:

Make your fixes and changes in this branch, test.

Step4:

When done, move to dev or master, click gitflow, then click “choose other action”.

Step5:

Choose “Finish hotfix”, select your hotfix name and click ok.

Step6:

This should merge your changes into both dev and master.

Step7:

You should now have some commits to push on both dev and master. Click push.. that should be it

 

Using gitflow: Scenario:  New feature to build

Step1:

Ensure all branches are up to date (ie pull all). Click the gitflow button in source tree and choose new “start new feature”.

Step2:

This will auto create a new branch with the name of your feature (only numbers, underscores and letters)

Step3:

Create your new code

Step4:

When done, move to dev or master, click gitflow, then click “choose other action”.

Step5:

Choose “Finish feature”, select your feature name and click ok.

Step6:

This should merge your changes into both dev and NOT master.

Step7:

You should now have some commits to push on both dev only. Click push.. that should be it. Your new feature will be in dev and not master and your feature branch should now not be visible to you (except in the orgins)

 

Using gitflow. Scenario:  Releasing a batch of features

Step1:

With all your branches up to date, and all the features you want to release finished (ie from above – in the dev branch). Click gitflow and create new release.

Step2:

This will auto create a new branch with the name of your release (only numbers, underscores and letters).

Step3:

Test all the features working together. Any bug that is found, make the fix to the code here in this release branch.

Step4:

When done, move to dev or master, click gitflow, then click “choose other action”.

Step5:

Choose “Finish release”, select your release name and click ok.

Step6:

This should merge your changes into both dev AND master.

Step7:

You should now have some commits to push on both dev and master. Click push.. that should be it

CSS Rotate fix for blurryness in Chrome and Safari

Apply the following std css rules to rotate an element:

The result is ok, before you start putting text in it. As soon as you put some text in the rotated element (or any of its children) things get a little blurry.

This little line fixes the beer goggles:

How To Install, Setup, And Test Apache MPM-ITK with PHP on Ubuntu or Debian

How To Install, Setup, And Test Apache MPM-ITK with PHP on Ubuntu or Debian

MPM-ITK module – which lets you run a virtual host under a specific username. Unlike SuPHP – ITK will also make apache run as the specified user for everything – static content or dynamic. It is also far quicker than SuPHP. This will let you close up your public html folders and help keep rogue scripts from editing other users’ files. As an added bonus it also supports other Apache modules, such as Python.

This is also very handy when you rsync your files in dev to a dev server running multiple vhosts for all you busy developers.

Step 1 – Install apache2-mpm-itk

Step 2 – Make use of it in a virtual host

 

Moving a Subversion Repository to Another Server

 

Moving a Subversion Repository to Another Server

Moving a subversion repository from one server to another, while still preserving all your version history may seam like a daunting task, but fortunately it’s not too difficult.

Step 1: Backup your old Repository

The first thing you need when moving from one server to another is a dump of your subversion repository. Hopefully you are already creating dump’s with a backup script, but if not here’s how you can create a subversion dump file:

 

The dump file contains all the revisions you have ever made to your svn repository, so it will probably be quite large (it even includes files you may have deleted in a previous revision).

Step 2: Moving your svn dump file to another server

Now transfer the dump file on to your new subversion server, for this example we will be using rsync to another unix server running with ssh listening on port 32:

 

 Step 3: Create the new Repository

Create an empty repository in the final :

 

Step 4: Import your old repository into the new one

Next import your dump file:

 

You may want to force subversion to use the same UUID for the new repository as the old repository. To do this add –force-uuid to your svnadmin load command. In my case I wanted to do this. If you have already loaded your repository, there is a way to set the UUID at a later date, check the docs.

That’s it, you now have a replica of your old repository on your new server.

More…

What if someone committed a new revision to the old server during installation?
You can easily import the new revision, by creating an incremental dump on the old server:

 

Now to import that revision on your new server:

 

Can’t I just use a hotcopy to restore the repository?
It depends, hotcopies created with svnadmin hotcopy must be moved to a server with identical setup. You should have the same version of subversion installed on both servers, same operating system, etc.
Subversion dumps are designed to work with different versions of subversion, and are just more flexible. Hotcopies are handy to have, but I recommend creating both hotcopies and dumps as part of your backup plan.

Security hardening on Ubuntu Server 14.04

http://blog.mattbrock.co.uk/hardening-the-security-on-ubuntu-server-14-04/

The following is a straight copy from the above link for my own reference should the above resource vanish.

Security hardening on Ubuntu Server 14.04

Recently I’ve been involved with a project where I needed to perform some security hardening on Amazon Web Services EC2 instances running Ubuntu Server 12.04, so I used this excellent guide as a starting point, then I added, removed and modified things as needed.
I decided to take those procedures and modify them for Ubuntu Server 14.04 now that this new LTS version has been released. Some of the procedures from 12.04 no longer need to be performed, and some needed to be changed. The following guidelines are what I’ve ended up with. You might find these guidelines useful to varying extents on other Linux distributions, but there will be potentially very significant differences depending on which distro you’re using.
Assume that all these operations need to be performed as root, which you can either do with sudo or by logging in as root first. (I’ve noticed that Ubuntu users seem particularly averse to logging in as root, apparently preferring instead to issue an endless series of commands starting with sudo, but I’m afraid that kind of extra hassle is not for me, so I just log in as root first.)

Harden SSH

I generally regard it as a very sensible idea to disable any kind of root login over SSH, so in /etc/ssh/sshd_config change PermitRootLogin to no.
If SSH on your servers is open to the world then I also advise running SSH on a non-standard port in order to avoid incoming SSH hacking attempts. To do that, in /etc/ssh/sshd_config change Port from 22 to another port of your choice, e.g. 1022. Note that you’ll need to update your firewall or EC2 security rules accordingly.
After making changes to SSH, reload the OpenSSH server:

 

Limit su access to administrators only

It generally seems like a sensible idea to make sure that only users in the sudo group are able to run the su command in order to act as (or become) root:

 

Improve IP security

Add the following lines to /etc/sysctl.d/10-network-security.conf to improve IP security:

Load the new rules:

 

PHP hardening

If you’re using PHP, these are changes worth making in ‘/etc/php5/apache2/php.ini’ in order to improve the security of PHP:

  1. Add exec, system, shell_exec, and passthru to disable_functions.
  2. Change expose_php to Off.
  3. Ensure that display_errors, track_errors and html_errors are set to Off.

Apache hardening

If you’re using Apache web server, it’s worth making sure you have the following parameters set in /etc/apache2/conf-enabled/security.conf to make sure Apache is suitably hardened:

For these to take effect you’ll need to enable mod_headers:

Then restart Apache:

 

Install and configure ModSecurity

If you’re using Apache, the web application firewall ModSecurity is a great way to harden your web server so that it’s much less vulnerable to probes and attacks. Firstly, install the necessary packages:

 

Prepare to enable the recommended configuration:

 

Then edit /etc/modsecurity/modsecurity.conf:

  1. Set SecRuleEngine to On to activate the rules.
  2. Change SecRequestBodyLimit and SecRequestBodyInMemoryLimit to 16384000 (or higher as needed) to increase the file upload size limit to 16 MB.

Next, install the Open Web Application Security Project Core Rule Set:

 

To add the rules to Apache, edit /etc/apache2/mods-available/security2.conf and add the following line near the end, just before :

Restart Apache to active the new security rules:

Install and configure mod_evasive

If you’re using Apache then it’s a good idea to install mod_evasive to help protect against denial of service attacks. Firstly install the package:

Next, set up the log directory:

Configure it by editing /etc/apache2/mods-available/evasive.conf:

  1. Uncomment all the lines except DOSSystemCommand.
  2. Change DOSEmailNotify to your email address.

Link the configuration to make it active in Apache:

Then activate it by restarting Apache:

Install and configure rootkit checkers

It’s highly desirable to get alerted if any rootkits are found on your server, so let’s install a couple of rootkit checkers:

Next, let’s make them do something useful:

  1. In /etc/chkrootkit.conf, change RUN_DAILY to "true" so that it runs regularly, and change "-q" to "" otherwise the output doesn’t make much sense.
  2. In /etc/default/rkhunter, change CRON_DAILY_RUN and CRON_DB_UPDATE to "true" so it runs regularly.

Finally, let’s run these checkers weekly instead of daily, because daily is too annoying:

Install Logwatch

Logwatch is a great tool which provides regular reports nicely summarising what’s been going on in the server logs. Install it like this:

Make it run weekly instead of daily, otherwise it gets too annoying:

Make it show output from the last week by editing /etc/cron.weekly/00logwatch and adding --range 'between -7 days and -1 days' to the end of the /usr/sbin/logwatch command.

Enable automatic security updates

N.B. Be warned that enabling automatic updates can be potentially dangerous for a production server in a live environment. Only enable this for a server in such an environment if you really know what you are doing.
Run this command:

Then choose Yes.

Enable process accounting

Process accounting keeps track of all sorts of details about which commands have been run on the server, who ran them, when, etc. It’s a very sensible thing to enable on a server where security is a priority, so let’s install it:

To show users’ connect times, run ac. To show information about commands previously run by users, run sa. To see the last commands run, run lastcomm. Those are a few commands to give you an idea of what’s possible; just read the manpages to get more details if you need to.

Things I haven’t covered

There are some additional issues you might want to consider which I haven’t covered here for various reasons:

  1. This guide assumes your Ubuntu server is on a network behind a firewall of some kind, whether that’s a hardware firewall of your own, EC2 security rules on Amazon Web Services, or whatever; and that the firewall is properly configured to only allow through the necessary traffic. However, if that’s not the case then you’ll need to install and configure a firewall on the Ubuntu server itself. The recommended software for this on Ubuntu is ufw.
  2. If you’re running an SSH server then you’re often told that you must install a tool such as fail2ban immediately if you don’t want your server to be hacked to death within seconds. However, I’ve maintained servers with publicly-accessible SSH servers for many years, and I’ve found that simply moving SSH to a different port solves this problem far more elegantly. I monitor logs in order to identify incoming hacking attempts, and I haven’t seen a single one in the many years I’ve been doing this. However, using this “security by obscurity” method doesn’t mean that such an attack can’t happen, and if you don’t watch your logs regularly and respond quickly to them as I do, then you would be well advised to install fail2ban or similar as a precaution, in addition to moving your SSH server to another port as described above.
  3. Once you’ve hardened your server, you’re advised to run some vulnerability scans and penetration tests against it in order to check that it’s actually as invincible as you’re now hoping it is. This is a topic which requires a post all of its own so I won’t be covering it in any detail here, but a good starting point if you’re not already familiar with it is the excellent Nmap security scanner.
Posted on