How to downgrade a package via apt-get

"apt-get" supports choosing a particular version or targeted release.
Take a look below:

sudo apt-get install <package-name>=<package-version-number> 

or

sudo apt-get -t=<target-release> install <package-name>

Both can be used to downgrade a package to a specific version.

How to remove a broken Debian package

To manually uninstall the broken package run the two commands below as root

mv /var/lib/dpkg/info/[my-package].* /tmp/ 
dpkg --remove --force-remove-reinstreq [my-package]

Erstellen eines Debian/Ubuntu-Repositories

Zu installierende Pakete

Zum Aufbau eines APT-Repositories sind folgende Pakete zu installieren:

• gnupg
• reprepro
• ruby
• rubygems
• apache2

Die Pakete sind wie folgt zu installieren (bei Bedarf ein sudo voranstellen):

Installation der benötigten Pakete

apt-get install gnupg apt-get install reprepro apt-get install apache2 apt-get install ruby apt-get install rubygems gem install fpm cd /usr/bin ln -s /var/lib/gems/1.9.1/gems/fpm-0.4.39/bin/fpm

fpm ist in keinem Repository und muss deshalb separat installiert werden.

Konfiguration der Pakete

GnuPG

Zum signieren der Pakete muss ein GPG-Key erstellt werden, dies geschieht durch das Kommando:

Erstellung eines GPG-Keys

gpg --gen-key

Es erscheinen mehrere Abfragen, die zu beantworten sind. In den meisten Fällen sind die voreingestellten Defaultwerte in Ordnung und können mit Return übernommen werden. Der Signaturkey wird mit folgenden Parametern erstellt:

• Art des Schlüssels: RSA und RSA (voreingestellt)
• Schlüssellänge: 2048
• Gültigkeit: 0 = Schlüssel verfällt nie
• Ihr Name ("Vorname Nachname"): Meine Firma
• Email-Adresse: ebusiness-entwicklung@my-company.com
• Kommentar: Signatur Key
• Passphrase:

Es wird sowohl ein Public- als auch ein Private-Key generiert, beide werden im Verzeichnis ~/.gnupg abgelegt, pubring.gpg enthält die öffentlichen Schlüssel, secring.gpg die privaten. Die Privaten Schlüssel sind nicht weiterzugeben. Der Public-Key wird später exportiert.

reprepro

Anlage des Repository-Verzeichnisses:

Anlage des Repository-Verzeichnisses

mkdir -p /var/packages/debian/conf chown -R jenkins:utempter /var/packages chmod -R 755 /var/packages

Im conf Verzeichnis werden drei Dateien angelegt, die distribution-Datei definiert, für welche Distribution die hier enthaltenen Pakete zur Verfügung stehen:

/var/packages/debian/conf/distributions

Origin: Firma GmbH Label: Firma GmbH Codename: wheezy Architectures: i386 amd64 Components: default release stable testing Description: APT Repository SignWith: ebusiness-entwicklung@my-company.com DebOverride: override.wheezy DscOverride: override.wheezy

Note 1: wenn die Strukture wurde geändert, dann ausführen

reprepro --delete clearvanished

Note 2: to remove all packages from a specific project

reprepro remove wheezy my-project

Für arbeiten auf der Konsole mit Reprepro, Ihr musst zuerst den Path exportieren

reprepro path

export REPREPRO_BASE_DIR=/var/packages/debian

Reprepro Wiki
Eine leere Override-Datei wird passend zur Festlegung in der distribution-Datei erstellt:

override Datei

touch override.wheezy

Zuguterletzt wird die options Datei angelegt mit folgendem Inhalt:

options Datei

verbose basedir .

Der vorhin erstellte gpg-Schlüssel wird ins Repository-Verzeichnis extrahiert:

Export des Public GPG-Keys

gpg --armor --output /var/packages/ebusiness.key --export ebusiness-entwicklung@my-company.com

Einrichten des jenkins-Servers

Achtung: Beim Paketbau durch "fpm" werden alle Daten in ein temporäres Verzeichnis kopiert, per Default ist das /tmp. Aufgrund der Größe der Hybris-Pakete muss dies per --workdir Parameter umgestellt werden, im Root-Dateisystem wird der Platz sonst schnell zu knapp. Für den Fall wurde unter /opt/fpm/tmp/ ein passendes Verzeichnis angelegt.
Damit der jenkins-Server beim Bau der Shops Debian Pakete erzeugt und diese ins Repository legt ist ein zusätzlicher Verarbeitungsschritt (Shell ausführen) einzufügen mit folgenden folgende Befehlen:

Jenkins Konfiguration Beispiel

VERSION=`cat ${WORKSPACE}/hybris/config/version.properties | sed -e 's|version=V ||g'` VERSION=${VERSION}.${BUILD_NUMBER} touch temp.deb rm *.deb mkdir -p temp/opt mkdir -p temp/etc/init.d cp scripts/hybristomcat temp/etc/init.d/ chmod 755 temp/etc/init.d/hybristomcat rm -rf hybris/temp rm -rf hybris/data/csv rm -rf hybris/data/impex rm -rf hybris/data/luceneindex cp -r hybris temp/opt/ rm -rf temp/opt/hybris/log/junit rm -f temp/opt/hybris/bin/platform/*.log rm -f temp/opt/hybris/bin/platform/tomcat-6/bin/wrapper-linux-x86-32 cp temp/opt/hybris/bin/platform/tomcat-6/bin/wrapper-linux-x86-64 temp/opt/hybris/bin/platform/tomcat-6/bin/wrapper-linux-x86-32 find . -name '*.class' -or -name '*.java' -or -name '*.conf' -or -name '*.properties' | xargs perl -pi -e 's/opt\/jenkins\/jobs\/my-job\/workspace/opt/g' find . -name '*.conf' | xargs perl -pi -e 's/\/usr\/lib\/jvm\/java-7-oracle\/jre\/bin\/java/\/usr\/bin\/java/g' sed -i -e 's|/opt/jenkins/jobs/.*/workspace/hybris|/opt/hybris|g' temp/opt/hybris/bin/platform/tomcat-6/conf/server.xml sed -i -e 's|/opt/jenkins/jobs/.*/workspace/hybris|/opt/hybris|g' temp/opt/hybris/bin/platform/tomcat-6/conf/server-minimal.xml fpm -s dir -t deb --workdir /opt/fpm/tmp/ --name "my-project" --version "${VERSION}" -a all -C "temp" --pre-install "${WORKSPACE}/temp/opt/hybris/config/automation/pre-install.sh" --post-install "${WORKSPACE}/temp/opt/hybris/config/automation/post-install.sh"  --before-remove "${WORKSPACE}/temp/opt/hybris/config/automation/pre-uninstall.sh"  --after-remove "${WORKSPACE}/temp/opt/hybris/config/automation/post-uninstall.sh" . export REPREPRO_BASE_DIR=/var/packages/debian lockfile-create /var/lock/createrepo reprepro -C default includedeb wheezy my-package_${VERSION}_all.deb lockfile-remove /var/lock/createrepo

Pre- und Postinstall-ScripteMit Pre- und Postinstall-Scripten können Aktionen vor und nach der Installation des Pakets durchgeführt werden. Es handelt sich dabei um gewöhnliche Shell-Scripte. Für die Hybris-Pakete nutzen wir das Preinstall-Script um den Hybris-Server herunterzufahren, falls bereits einer installiert ist

pre-install.sh

#! /bin/bash if test -e /etc/init.d/hybristomcat ; then   /etc/init.d/hybristomcat stop fi

Das Postinstall-Script ist umfangreicher, hier werden vier Funktionen abgedeckt:

1. durchführen eines Datenbankupdates, falls eine Datei namens /opt/deploydir/updatedb existiert
2. einspielen von Impex-Dateien aus dem Verzeichnis /opt/deploydir/impex, falls diese existieren
3. starten des Hybris-Servers
4. verteilen statischer Inhalte auf vorgeschaltete Apache-Server, wenn vorhanden

Die Datenbankänderungen werden vor dem Start des Hybris-Servers durchgeführt, damit ist sichergestellt, dass dieser beim Start bereits eine passende Datenbank vorfindet. Das Verteilen der statischen Daten (Bilder, CSS, HTML-Seiten, ...) wurde hinter den Stat des Servers verlagert, da dieser einige Zeit in Anspruch nimmt, auch nachdem das Startscript abgearbeitet wurde und der Tomcat läuft, braucht Hybris noch, so kann also parallel der statische Inhalt verteilt werden.

post-install.sh

#! /bin/bash # make a database update if necessary if test -e "/opt/deploydir/updatedb"; then     cd /opt/hybris/bin/platform     mkdir -p /opt/hybris/config/ci_build/libcd     . ./setantenv.sh     ant updatesystem -Dtenant=master     rm -f "/opt/deploydir/updatedb"     cd - fi   # import impex files if test -d "/opt/deploydir/impex"; then     numimpex=`ls -la /opt/deploydir/impex/*.impex 2>/dev/null | grep -c ".impex"`     echo "Importing ${numimpex} files..."     if test ${numimpex} -gt 0; then         cd /opt/hybris/bin/platform         mkdir -p /opt/hybris/config/ci_build/libcd         . ./setantenv.sh         ant runcronjob -Dcronjob="DeploymentImpexImportJob" -Dtenant=master         cd -     fi fi   # start hybris tomcat /etc/init.d/hybristomcat start   # copy static content to apache directories (if available) USE_CLUSTER="false" if test -e "/etc/hybriscluster"; then     . /etc/hybriscluster     if test "${HYBRIS_CLUSTER_NODES}X" != "X"; then         USE_CLUSTER="true"     fi fi if test "${USE_CLUSTER}" = "true"; then     for NODE in ${HYBRIS_CLUSTER_NODES}; do         if test -e "/opt/${NODE}/webroot"; then             cp -r /opt/hybris/bin/custom/my-extension/web/webroot/* /opt/${NODE}/webroot/             rm -rf /opt/${NODE}/webroot/WEB-INF         fi     done fi

Pre- und Postuninstall-Scripte

Mit Pre- und Postuninstall-Scripten können Aktionen vor und nach der deInstallation des Pakets durchgeführt werden. Es handelt sich dabei um gewöhnliche Shell-Scripte. Für die Hybris-Pakete nutzen wir das Preuninstall-Script um den Hybris-Server herunterzufahren, falls bereits einer installiert ist, normal sollte das Start-/Stopscript nach der Deinstallation nicht mehr vorhanden sein, das Script ist reine Vorsichtsmaßnahme

pre-uninstall.sh

#! /bin/bash if test -e /etc/init.d/hybristomcat ; then   /etc/init.d/hybristomcat stop fi

Das post-uninstall.sh-Script ist vorhanden, führt aber derzeit keine Aktionen aus. Der Versuch /opt/hybris damit zu löschen führte leider bei Udates zu defekten Systemen, da das Script anscheinend erst nach Installation des neuen Pakets lief und das Verzeichnis dann immer fehlte.

Apache Server für Zugriff auf das Repository konfigurieren

Der Apache Server sorgt für den Zugriff über http auf das Repository. Es wird ein weiterer Virtual Host angelegt, die Konfigurationsdatei wird in /etc/apache2/sites-available angelegt, in dem Fall  hat sie den kompakten Namen "apt" und folgenden Inhalt:

apt apache virtual host

<VirtualHost *>         DocumentRoot /var/packages         ServerName apt.intranet.my-company.com         ErrorLog /var/log/apache2/apt-error.log            LogLevel warn            CustomLog /var/log/apache2/apt-access.log combined         ServerSignature On            # Allow directory listings so that people can browse the repository from their browser too         <Directory "/var/packages">                 Options Indexes FollowSymLinks MultiViews                 DirectoryIndex index.html                 AllowOverride Options                 Order deny,allow                 Deny From All                 allow from 10.9.                 Satisfy ANY         </Directory>            # Hide the conf/ directory for all repositories         <Directory "/var/packages/*/conf">                 Order allow,deny                 Deny from all                 Satisfy all         </Directory>            # Hide the db/ directory for all repositories         <Directory "/var/packages/*/db">                 Order allow,deny                 Deny from all                 Satisfy all         </Directory> </VirtualHost>

Der ServerName muss definiert sein, sollte er nicht über den DNS bekannt gemacht werden, sind auf allen Rechnern, die darauf zugreifen sollen, Einträge in die /etc/hosts Datei vorzunehmen.
Zur Aktivierung des Servers wird die Konfiguration mit "a2ensite apt" aktiviert und der Apache mit "/etc/init.d/apache2 reload" dazu gebracht, die Konfiguration neu einzulesen.

Einrichtung der Server, die auf das Repository zugreifen

Einbinden des Public-Keys

Damit die Signatur der Pakete geprüft werden kann, muss der Public-Key eingebunden werden:

import public key

wget http://apt.intranet.my-company.com/ebusiness.key apt-key add ebusiness.key

Wenn alles funktioniert hat, kann jetzt das Repository eingebunden werden, dazu reicht folgender Eintrag in der /etc/apt/source.ist.

/etc/apt/sources.list

deb http://apt.intranet.my-company.com/debian wheezy default

Wie wird das Paket aktualisiert

Bei den Testmaschinen erfolgen Updates vollautomatisch in der Nacht mit Hilfe von cron-apt. Soll das Paket manuell aktualisiert werden, ist folgendes einzugeben

Update the project

apt-get update && apt-get --only-upgrade install my-project

Wie wird die Datenbank aktualisiert

Ein "Systemupdate" wird immer dann angestoßen, wenn bei Installation des Pakets die Datei /opt/deploydir/updatedb existiert

Update database

cd /opt/deploydir touch updatedb apt-get update && apt-get --only-upgrade install my-project

Wie werden neue/geänderte Datensätze in die Datenbank eingefügt

Neue oder geänderte Datensätze können wie immer über Impex-Dateien eingespielt werden. Das Debian Package prüft nach der Installation, nach einem eventuell nötigen Datenbankupdate und noch vor dem Start des Servers, ob in dem Verzeichnis /opt/deploydir/impex/ Dateien mit der Endung ".impex" existieren und spielt sie per Cronjob ein.

How to install and analyse Java code with SonarQube

Installation process

To give a quick try at SonarQube, just follow the steps below.

Get Started in Two Minutes

1. Download and unzip the SonarQube distribution (let's say in "C:\sonarqube" or "/opt/sonarqube")
2. Start the SonarQube server:

# On Windows, execute: C:\sonarqube\bin\windows-x86-xx\StartSonar.bat    # On other operating system, execute: /opt/sonarqube/bin/sonar.sh console

3. Download and unzip the SonarQube Runner (let's say in "C:\sonar-runner" or "/opt/sonar-runner")
4. Download and unzip some project samples (let's say in "C:\sonar-examples" or "/opt/sonar-examples")
5. Analyze a project:

# On Windows: cd C:\sonar-examples\projects\languages\java\sonar-runner\java-sonar-runner-simple C:\sonar-runner\bin\sonar-runner.bat    # On other operating system: cd /opt/sonar-examples/projects/languages/java/sonar-runner/java-sonar-runner-simple /opt/sonar-runner/bin/sonar-runner

6. Browse the results at http://localhost:9000 (default System administrator credentials are admin/admin)

Install SonarQube server in Linux (Ubuntu/Debian)

Edit "/etc/apt/sources.list" and add:

# SonarQube deb http://downloads.sourceforge.net/project/sonar-pkg/deb binary/

And run the below commands as sudo:

apt-get update apt-get install sonar /etc/init.d/sonar start

After start the sonar service go to your web-browser on http://localhost:9000/ and login on it with admin/admin.
Next, go to "Settings -> Update Center -> Plugin Updates" and update the Java plugin.
Restart the server with:

/etc/init.d/sonar restart

Now you can analyse your code in Eclipse with your local sonar server.

Install SonarQube server plug-ins

Setup the proxy in your local server

Edit "/opt/sonar/conf/sonar.properties" file and add:

#-------------------------------------------------------------------------------------------------- # UPDATE CENTER   # The Update Center requires an internet connection to request http://update.sonarsource.org # It is enabled by default. sonar.updatecenter.activate=true   # HTTP proxy (default none) http.proxyHost=proxy.my-proxy-url.com http.proxyPort=8080   # proxy authentication. The 2 following properties are used for HTTP and SOCKS proxies. http.proxyUser=my-proxy-user http.proxyPassword=my-proxy-pass

Save it and restart Sonar again.

Choose the plug-ins

1. Go to "Settings" -> "Update Center" -> "Available Plugins"
2. Install:
   1. Checkstyle
   2. PMD
   3. fb-contrib
3. Restart Sonar server

Import production rules into local Sonar server

1. Export production rules from
   http://sonar.my-company.com/profiles
2. Choose "Sonar way with Findbugs" profile and back it up.
3. Go to your local server
   http://localhost:9000/profiles
4. Delete your local "Sonar way with Findbugs" profile
5. Restore the previous profile using in this case the production profile file.
6. Set this one as default

How to set up Active Directory validation with LDAP in SonarQube server

Open the file "/opt/sonar/conf/sonar.properties" and add below lines:

# LDAP Configuration sonar.security.realm=LDAP sonar.security.savePassword=true sonar.security.updateUserAttributes=true sonar.authenticator.downcase=true sonar.authenticator.createUsers=true   ldap.authentication=simple ldap.url=ldap://my-ldap-host-server ldap.bindDn=cn=jiraldapquery,ou=Serviceaccounts,ou=X-ADM,dc=root,dc=local ldap.bindPassword=HERE-THE-PASSWORD    # User Configuration ldap.user.baseDn=OU=standarduser,OU=X-RIS,DC=root,DC=local ldap.user.request=(&(objectClass=user)(sAMAccountName={login})) ldap.user.realNameAttribute=cn ldap.user.emailAttribute=mail    # Group Configuration ldap.group.baseDn=OU=groups,OU=X-RIS,DC=root,DC=local ldap.group.request=(&(objectClass=group)(member={distinguishedName}))

Restart the server with "/etc/init.d/sonar start"
More info here http://docs.codehaus.org/display/SONAR/LDAP+Plugin

Run a local analize with Gradle

Install Gradle

In Ubuntu Linux the process is quite easy:

sudo apt-get install gradle

Note: install at least version 1.12 (the old ones doesn't support the sonar plugin)
To get the last Gradle version you need to add the below lines into your "/etc/apt/sources.list" (only for Debian distributions) and import the pgp key that's used to sign the repository

source.list snippet

deb http://ppa.launchpad.net/cwchien/gradle/ubuntu YOUR_UBUNTU_VERSION_HERE main deb-src http://ppa.launchpad.net/cwchien/gradle/ubuntu YOUR_UBUNTU_VERSION_HERE main

Import of the PGP-Key

apt-key adv --keyserver keyserver.ubuntu.com --recv-key D7CC6F019D06AF36

Start code analysis with SonarRunner

cd [PROJECT_BASE_DIR]/bin/custom gradle sonarRunner

That's all :-)

Install and setup IDEs support

Eclipse IDE plugin

Add the below link into your "Available Software Sites"

http://dist.sonar-ide.codehaus.org/eclipse/
On your Eclipse you need to set some properties, for example for BayWa project:

• Window -> Preferences -> SonarQube -> Preview Analysis Properties and then click on "New"

Sonar BayWa properties

sonar.buildbreaker.skip = true sonar.sources = src sonar.binaries = classes

• Add the Sonar server into "Servers" section with below values:

Server URL = http://localhost:9000 User = admin Password = admin

• For each project select from context menu: "SonarQube" -> "Change ProjectAssociation..", the connection should be detected automaticly, just use "Finish" and analyes should start.

IntelliJ IDE plugin

Set up SonarQube in IntelliJ (take care with this plugin, it doesn't support multiple modules in a project without Maven)
Set up SonarQube with the Communitiy Edition plugin