SKM IT World

Just another blog about IT


Leave a comment

How to Configure Apache2 as Forward and Reverse Proxy

This is a cook recipe to configure an Apache2 as a forward and reverse proxy on Debian-based Linux systems like Ubuntu or Debian itself.

Installation

It is assumed that the apache2 package is already installed on your system. For the proxy feature, we have to install the Apache2 module libapache2-mod-proxy-html on the system and activate theses Apache modules. At the end, Apache2 has to be restarted, so that the modules can be used.


sudo apt-get install libapache2-mod-proxy-html
sudo a2enmod proxy
sudo a2enmod proxy_html
sudo a2enmod proxy_http
sudo service apache2 restart

Configuration Forwarding and Rewarding

We want to forward the URL request http://jenkins.mycompany.com to http://jenkins.mycompany.com:8083 and rewarding http://jenkins.mycompany.com:8083 to http://jenkins.mycompany.com for every response.

For that, we have to create a so-called Virtual Host in Apache2. It is easiest to copy the configuration of the default one and adjust it.


cd /etc/apache2/sites-available
sudo cp 000-default.conf jenkins_ci.conf

It is best practice to create one conf file per Virtual Host. Adding and removing Virtual Host is easier with this approach.

The content of the Virtual Host configuration should look similar to the following one:


<VirtualHost jenkins.mycompany.com:80>
ServerName jenkins.mycompany.com

ServerAdmin webmaster@localhost

ProxyRequests Off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPass / http://localhost:8083/
ProxyPassReverse / http://localhost:8083/

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

We have to add the host name (in this case jenkins.my.company.com) to the line 1 and 2, so that Apache2 knows for which host name is this Virtual Host. In line 11 and 12 the mapping is configured (in this case, everything that call the host name directly should be forwarded to http://localhost:8083; the opposite for rewarding).

At the end this configuration has to be enabled.


sudo a2ensite jenksin_ci.conf
sudo service apache2 reload

 

Further Information

  1. https://wiki.ubuntuusers.de/Apache/mod_proxy_html/
  2. https://wiki.ubuntuusers.de/Apache/Virtual_Hosts/

 

Advertisements


Leave a comment

Pimp My Git – Manage Different Git Identities

I usually work on different Git projects that need different Git identities. My work flow for new repositories was

  1. Clone new repository.
  2. Go to cloned repository.
  3. If it is necessary to change the Git identity, call a shell script that runs `git config user.name “Sandra Parsick”; git config user.email sparsick@web.de`

I was never happy with this solution, but it works. Fortunately, a tweet of @BenediktRitter and one of @wosc suggest two alternatives to my method.

The first method bases on the Git feature “Conditional Includes” (required Git Version at least 2.13). The idea is that you define a default Git identity and separate Git identities per specific directory. That means, every repository, that is cloned beneath one of the specific directory, has automatically its specified Git identities.

The second method bases on a Python script, that is inspired by the Mercurial extension hg-persona. The idea is that you can individually set a Git identity per Git repository. It is an one command replacement for the git config user.* command serie.

In the next two sections I’d like to summarize how to set up and how to use these two methods. I have tested it on a Debian-based system. Let’s start with the first one.

Summarize Git identity for several Git repositories

As above described, this method bases on the Git feature “Conditional Includes”. Therefore, ensure you have installed your Git client in at least version 2.13 . Assume, we want to have two Git identities, one for Github and one for work. Therefore, create two .gitconfig files in your home folder.


touch ~/.gitconfig_github
touch ~/.gitconfig_work

Then add the specific Git identity in respective .gitconfig files.


~/.gitconfig_github

[user]
   name = YourNameForGithub
   email = name@forgithub.com

~/.gitconfig_work

[user]
   name = YourNameForWork
   email = name@forwork.com

The next step is to add these two .gitconfig files to our global one and to specify when to use them.

~/.gitconfig

[user]
   name = defaultName
   email = default@email.com

[includeIf "gitdir:~/workspace_work/"]
   path = .gitconfig_work

[includeIf "gitdir:~/workspace_github/"]
   path = .gitconfig_github

Now, every repository, that is cloned beneath ~/workspace_work/, has automatically the Git identity for Work (.gitconfig_work) and every repository, that is cloned beneath ~/workspace_github/, has automatically the Git identity for Github (.gitconfig_github). Otherwise, the default Git identity is used.

Setting Git identity individually per Git repository

For the second method, you have to install ws.git-persona from PyPI.


sudo apt-get install pip # if PyPI isn't install
pip install ws.git-persona

Then, open your global ~/.gitconfig and add your personas. In our cases, we add two personas, one for Github and one for work.


~/.gitconfig

[persona]
  github = YourNameForGithub &lt;name@forgithub.com&gt;
  work = YourNameForWork &lt;name@forwork.com&gt;

In the next step, we want to switch our Git identity in a Git repository. This is now possible with the command git-persona. In the following example we switch to the identity for Github and then to the identity for work.


> git-persona -n github
Setting user.name="YourNameForGithub", user.email="name@forgithub.com"
> git config user.name
YourNameForGithub
> git config user.email
name@forgithub.com
> git-persona -n work
Setting user.name="YourNameForWork", user.email="name@forwork.com"
> git config user.email
name@forwork.com
> git config user.name
YourNameForWork

If you have other methods to manage different Git identities, let me know it and write a comment.

 

Links

  1. Blog post about Git feature “Conditional Includes”.
  2. Github repository of git-personas.


1 Comment

Pimp My Git – Git Mergetool

I like to work with git on the command line. But in some cases I prefer UI support. For example, solving merge conflicts is such a case. Git has a command mergetool, which can open a graphical tool to solve merge conflicts. But before you can use this command, you had to configure it. In this blog post I’d like to show you how to configure mergetool and how to use it.

Configuration

First at all, open a shell on Linux. On Windows, open Git Bash. Then choose a graphic tool that should support you solving merge conflicts. git mergetool –tool-help shows a list which tools are supported on your machine


 sparsick@sparsick-ThinkPad-T430s > git mergetool --tool-help
'git mergetool --tool=<tool>' may be set to one of the following:
                araxis
                kdiff3
                meld

The following tools are valid, but not currently available:
                bc
                bc3
                codecompare
                deltawalker
                diffmerge
                diffuse
                ecmerge
                emerge
                gvimdiff
                gvimdiff2
                gvimdiff3
                opendiff
                p4merge
                tkdiff
                tortoisemerge
                vimdiff
                vimdiff2
                vimdiff3
                winmerge
                xxdiff

Some of the tools listed above only work in a windowed
environment. If run in a terminal-only session, they will fail.

This command shows two lists. The first list shows all tools that are supported by git and that are available on your machine (in sample, it is araxis, kdiff3 and meld). The second list shows that are also supported by git, but they aren’t install on your machine.

I use meld as graphical tool. It’s runnable on Windows and Linux. If you haven’t install meld on your machine, then it’s now the right time to do it or choose another tool.

We want to set mergetool globally for all our repositories.


sparsick@sparsick-ThinkPad-T430s > git config --global merge.tool meld
sparsick@sparsick-ThinkPad-T430s > git mergetool
No files need merging

If git mergetool returns more than No files need merging, then the path to your graphic tool isn’t set in your $PATH system variable (The normal case on Windows systems). It’s possible to set the path to the graphical tool directly in git.

sparsick@sparsick-ThinkPad-T430s > git config --global mergetool.meld.path /c/Program\ Files\ \(x86\)/Meld/Meld.exe</pre>

Bear two important things in mind: mergetool is written without a dot between merge and tool and meld is a placeholder for the name of the graphical tool in the above sample. If you use another tool such like vimdiff, then the config key is called mergetool.vimdiff.path .

Now git mergetool is ready to use.

Usage

Now I’d like to demonstrate how to use git mergetool. It is used in when we have merge conflicts during a merge action. Let’s say we want to merge branch branch1 into master and this merge will have some merge conflicts.


sparsick@sparsick-ThinkPad-T430s > git merge branch1

Auto-merging test
CONFLICT (content): Merge conflict in test
Automatic merge failed; fix conflicts and then commit the result.

Now, we want to solve these conflicts with a graphical tool (in the example, it’s meld). git mergetool on the command line open the graphical tool of our choice.

sparsick@sparsick-ThinkPad-T430s > git mergetool

Merging:
test

Normal merge conflict for 'test':
{local}: modified file
{remote}: modified file

After solving the merge conflicts, the change has to commit.

sparsick@sparsick-ThinkPad-T430s > git status

On branch master
All conflicts fixed but you are still merging.
(use "git commit" to conclude merge)

Changes to be committed:

modified:   test

Untracked files:
(use "git add <file>..." to include in what will be committed)

test.orig
sparsick@sparsick-ThinkPad-T430s > git commit

You can see that we have a new untracked file test.orig . This is a backup of the merged file created by mergetool. You can configure that this backup should be removed after a successful merge.

sparsick@sparsick-ThinkPad-T430s > git config --global mergetool.keepBackup false

Further files are created when using git mergetool:

sparsick@sparsick-ThinkPad-T430s > git status

On branch master
Untracked files:
(use "git add ..." to include in what will be committed)

test.BACKUP.7344
test.BASE.7344
test.LOCAL.7344
test.REMOTE.7344

If only these files are currently untracked, then a git clean can help. Otherwise they have to be removed manually.

sparsick@sparsick-ThinkPad-T430s > git clean -f

Removing test.BACKUP.7344
Removing test.BASE.7344
Removing test.LOCAL.7344
Removing test.REMOTE.734

Links

  1. Meld Homepage
  2. git mergetool Documentation


Leave a comment

Automatic Tomcat 8.5 Installation and Configuration as Windows Service

If you want to install Tomcat on Windows system as a service, you’ll get the recommendation to use the 32-/64-Bit Windows Service Installer. If you want to install the Tomcat manually, it’s fine. But you can’t use this installer for an automatic installation and configuration of Tomcat, because the installer is UI-based. The next sections explain how you can install and configure Tomcat on a CMD.

Tomcat Installation

  1. Download from the Apache Tomcat 8.5 download page the Core 64-bit Windows zip (or the 32-Bit zip).
  2. Unzip it (for example to C:\tomcat\)

That’s it. Now we have a ready-to-use Tomcat with default configuration values. But it isn’t install as a service.

Installation and Configuration As Windows Service

  1. Go to the bin folder in the installation folder of Tomcat (in the example  it’s C:\tomcat\apache-tomcat-8.5.11\bin)
  2. Install Tomcat as service named tomcat8 by calling service.bat install <servicename>
    C:\tomcat\apache-tomcat-8.5.11\bin>service.bat install tomcat8
    
  3.  tomcat8.exe //US//<servicename> followed by configuration parameter configures the Tomcat service. For example:
    C:\tomcat\apache-tomcat-8.5.11\bin>tomcat8.exe //US//tomcat8 --Startup=auto --JavaHome="C:\Program Files\Java\jre1.8.0_112" --JvmMs=2048 --JvmMx=4096 ++JvmOptions=-Dkey=value
    
  4. Start the Tomcat service with net start <servicename>
    net start tomcat8
    
  5. You can check on http://localhost:8080 whether Tomcat is installed correctly.

The configuration example (step 3) shows how to configure the JVM (heap space, Java option etc.), where Java is installed and which start type should use for the service. The full list of the possible configuration parameter for the Tomcat service can be found in the Apache Tomcat’s Windows Service documentation.

Now we have everything together for writing a Powershell script that does these steps automatically.

 


Leave a comment

Migration Sonatype Nexus 2 to Nexus 3

I’d like to share my experience with migration Sonatype Nexus 2 to Nexus 3.

Starting Point

I used two Nexus instances:

  • A Nexus 2 Instance for Maven Repositories (2.13)
  • A Nexus 3 Instance for Bower Repositories (3.0.1)

Both instances had several types of repositories (host, proxy, group). The reason for this set up was that Sonatype recommended not to use Nexus 3 (pre 3.1) for Maven repositories and Nexus 2 doesn’t support Bower repositories.

Migration Path

  1. Update Nexus 2 instance to version 2.14.1 (Update Guide)
  2. Update Nexus 3 Instance to version 3.1 (Update Guide ). It’s important that you migrate to the new working directory layout.
  3. Follow the migration step for upgrading from version 2 to version 3 (Update Guide).
    • My scenario was Nexus 2 and Nexus 3 running on the same system.
    • I selected as Upgrade Method “File system copy”
    • I chose that only “repository configuration content” has to migrate.
  4. After a successful migration I had to adjust some configuration in Nexus and in the system that use Nexus:
    • Setup in Nexus 3 a new user for deploying artifacts.
    • Adjust URL to the repositories in Jenkins, Maven settings and deployment scripts.


Leave a comment

Summary of SoCraTes 2016 Session “Hey dude, where is my tool chain?” – Working on Windows as a Linux User aka Let’s talk about Windows

This year on the conference SoCraTes I hosted a session for the first time. It was about working on a Windows system from the perspective of a Linux user.  A big thank to @ndrssmn, who motivated to host this session.

@yooogan was so nice to summarize the session in the SoCraTes wiki (big thank for that).  But the wiki page is only accessible for SoCraTes participants, so we decided that I republish it on my blog. Enjoy it.


Console/Shell

  • Babun – Based on Cygwin, includes a CLI package manager (pact – like apt, yum, …) and preconfigured oh-my-zsh as shell
  • ConEmu – feature rich console emulator with tabs
  • Console2 (original)/(modified fork) – console emulator, multi tabs, configurable mouse behavior
  • PuTTYssh client (when you don’t have Babun/Cygwin anyway)

File Management

Text Editors

  • Notepad++ – all-purpose editor, syntax highlighting, file monitoring (tail -f)
  • Atom – editor; same settings in all your environments

Diff/Merge

Searching

Viewers

Documentation

  • Zim – Organize notes, saves to plain text
  • Greenshot – Screenshots, including obfuscation / comments, for documentation, connects to JIRA
  • yEd – multi-platform (Win/Linux/MacOS) graph editor, extensible palette, useful pictograms
  • Paint.NET – free image editor
  • GIMP – Swiss army knife for images

System

Disk Usage

  • RidNacs – graphical du
  • WinDirStat – even more colorful graphical du
  • ncdu – CLI, can be installed from Cygwin/Babun

Keyboard

  • WinCompose – a (X.org/X11 like) compose key for Windows – type äöë߀«»←↑↓→¡☺♥… like a boss!
  • SharpKeys – remap keyboard: CapsLockCtrl, ~Esc, etc.
  • AutoHotkey – very sophisticated keyboard macros / automation – full-fledged scripting language

Clipboard

  • PureText – remove formatting from pasted text
  • Ditto – clipboard manager

Pictures (taken from Twitter):

Let's talk about Windows, pt. 1
Let's talk about Windows, pt. 2
Let's talk about Windows, pt. 3

 


Leave a comment

My Lesson Learned From Doing Gilded Rose Kata

I’d like to share some of my thoughts about my approach to solve the Gilded Rose Refactoring Kata by Emily Bache. If you don’t know this kata, read the description for a better understanding. I have published my whole solution on GitHub . I tried to make a commit after every step, so you can keep track of my steps in the log of git. The chosen programming language is Java.

Solving Gilded Rose Step-By-Step

Let’s have a look at what I have done step-by-step.

Before adding the new feature, I wanted to refactor the given code base. Therefore, I started writing tests till I had a 100% line and branch coverage. During writing the tests, I was having the idea,, that the calculation of the quality is depended by the name of the item. Hence, the idea arose to use something similar like the Strategy Pattern. When I reached for 100% coverage, I tried to start with the implementation for the first strategy (“Aged Brie”). But I was unsure, what was my limit values for this first strategy. My problem was that I hadn’t tests for the limit values. So my first lessons learned was that 100% line or branch coverage doesn’t mean all test cases are covered. So I added tests for the limit values and finished implementing the “Aged Brie” strategy, added it to the original updateQualtity method (see below code snippet) and ran the tests. All tests were green.


ItemStrategy itemStrategy = new ItemStrategy();
...
for (int i = 0; i < items.length; i++) {
   if("Aged Brie".equals(items[i].name)) {
      items[i] = itemStrategy.updateQualityForAgedBrieItem(items[i]);
      continue;
   }

// original code follows
}

These cycle I repeated four times: Find missing test cases (mostly for limit values); add new tests for these cases; implement a further strategy; add this new strategy to the original updateQualtiy method and ran the tests. If the tests are green, the next cycle with a new strategy begins. At the end the extended updatedQuality method looked like the following code snippet.

ItemStrategy itemStrategy = new ItemStrategy();

...
for (int i = 0; i < items.length; i++) {
   if("Aged Brie".equals(items[i].name)) {
      items[i] = itemStrategy.updateQualityForAgedBrieItem(items[i]);
      continue;
   } else if ("Sulfuras, Hand of Ragnaros".equals(items[i].name)) {
      items[i] = itemStrategy.updateQualityForSulfurasItem(items[i]);
      continue;
   } else if("Backstage passes to a TAFKAL80ETC concert".equals(items[i].name)) {
      items[i] = itemStrategy.updateQualityForBackstagePassItem(items[i]);
      continue;
   } else {
      items[i] = itemStrategy.updateQualityForNormalItem(items[i]);
      continue;
   }

// commented out original code
}

My second Lessons Learned was “Refactoring needs time” and the refactoring wasn’t finished. The next steps were cleaning up unnecessary code and refactoring the strategy implementations like replacing if-else construct by ternary operator and extracting if-condition to private methods.

After that I implemented the new feature “conjured item” following the above describe work flow. After this step I could say “Ready”, but I was unhappy with the if-else if-else chain. Therefore, I decided to extract each strategy implementation to an own class (following the “classic” strategy pattern). That helps to replace the if-else if-else chain by an itemStrategyMap. So the next Lesson Learned was “The status ‘Ready’ depends by the definition”.
The last step was doing clean up and choosing better names for the interface and its method.


static Map<String, ItemStrategy> itemStrategyMap = new HashMap<>();

static {
   itemStrategyMap.put("Aged Brie", new AgedBrieItemStrategy());
   itemStrategyMap.put("Sulfuras, Hand of Ragnaros", new SulfurasItemStrategy());
   itemStrategyMap.put("Backstage passes to a TAFKAL80ETC concert", new BackstagePassItemStrategy());
   itemStrategyMap.put("Conjured", new ConjuredItemStrategy());
}

public void updateQuality() {
   for (int i = 0; i < items.length; i++) {
      ItemStrategy itemStrategy = itemStrategyMap.getOrDefault(items[i].name, new NormalItemStrategy());
      items[i] = itemStrategy.updateItem(items[i]);
   }
}

Let’s summarize the Lesson Learned:
1) 100% line or branch coverage doesn’t mean all test cases are covered.
2) Refactoring needs time.
3) The status ‘Ready’ depends by the definition.
These insights aren’t really new for me. I can often observe these insights in my daily work. Nevertheless, it was good to have these insights again, following the rule “learning through repetition” ☺

What I forgot

I stopped after that step. Thinking about it some days later, I have realized that there exists more improvements. For example, the tests from GildedRoseTest class could be extracted to separate test classes regarding to the specific strategy classes.