Categories
Middleware

Mit cURL weitergeleiteten Seiten (REDIRECT) folgen

Bei cURL Aufrufen landet man oft auf Seiten, die nur einen REDIRECT auf einen andere Seiten ausführen.

<

p class=”kasten”>
[root@0ccfa08b0829 /]# curl repository/yum>/strong>
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://repository/yum/">here</a>.</p>
</body></html>

So funktioniert es:

<

p class=”kasten”>
[root@0ccfa08b0829 /]# curl repository/yum -L
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html>
<head>
<title>Index of /yum</title>
</head>
<body>
<h1>Index of /yum</h1>
<ul><li><a href="/"> Parent Directory</a></li>
<li><a href="nginx-1.12.2-1.el6.ngx.x86_64.rpm"> nginx-1.12.2-1.el6.ngx.x86_64.rpm</a></li>
<li><a href="repodata/"> repodata/</a></li>
</ul>
</body></html>

Categories
ansible DevOps Docker Jinja Middleware YAML

Ansible Installation auf Windows 10 Systemen

Ansible kann lokal in der Windows Bash installiert und zusammen mit Visual Studio Code (https://code.visualstudio.com/) effektiv betrieben werden. Die Windows Bash muss installiert sein. Die Bash kann über den Windows Store installiert werden. Einfach nach Ubuntu suchen. Nach der Installation die bash starten.

PS C:\Users\user01> bash

Die eigentliche ansible Installation erfolgt im Windows Linux Subsystem mit diesen Befehlen. Der letzte Befehl fügt die ansible Kommandos zum Pfad hinzu, damit sie direkt aufrufbar sind.

sudo apt-get -y install python-pip python-dev libffi-dev libssl-dev
pip install --upgrade pip
pip install ansible --user
echo 'PATH=$HOME/.local/bin:$PATH' >> ~/.bashrc

<em>"pip install --upgrade pip"</em> ist nur der Schönheit halber enthalten, damit pip auch aktuell ist, sonst gibt es Warnungen. Das war es schon. Jetzt noch in Visual Studio Code (im Folgenden VSC genannt) die Erweiterung ansible installiert und ein erstes Playbook kann geschrieben werden:

---
- name: first Test
  hosts: all
  connection: local
  tasks:
    - debug: msg="Das lokal installierte Ansible funktioniert bestens!"

Download des Beispiels hier: firstPlaybook.yaml

Ganz wichtig sind die nicht vorhandenen Leerzeichen in den ersten beiden Zeilen, eine Leerzeile am Ende und keine Leerzeichen an den Zeilenenden.

Tipp: Visual Studio Code kann so eingestellt werden, die letzten beiden Punkte automatisch beim Speichern zu ändern. Dazu sind die beiden Zeilen in den Einstellungen von VSC anzupassen:

"files.trimFinalNewlines": true,
"files.trimTrailingWhitespace": true,

Im Terminal von VSC die bash aufrufen (einfach bash eingeben). Dann kann auch schon fast das Playbook ausgeführt werden. Das Inventory muss noch gepflegt werden. Konkret fehlen die Hosts Informationen.

  sudo mkdir /etc/ansible sudo vi /etc/ansible/hosts

Der Hostname der lokalen Maschine ist einzutragen. In diesen ersten einfachen Fall kann der Eintrag des Hostnamens ohne eine Gruppierung erfolgen, die Datei enthält also vorerst nur den Hostnamen oder einfach “localhost”.

ansible-playbook firstPlaybook.yaml --connection=local


PLAY [first Test] ********************************

TASK [Gathering Facts] ***************************
ok: [localhost] <br />
TASK [debug] *************************************
ok: [localhost] => {
"msg": "Das lokal installierte Ansible funktioniert bestens!"
}
<br />
PLAY RECAP ************************************
localhost : ok=2 changed=0 unreachable=0 failed=0

Weitergehende Tipps: Um Ansible und Jinja Templates zu testen, gibt es 2 extrem nützliche Seiten:

YAML Online Tests: http://yaml-online-parser.appspot.com/ JINJA2 Online Tests: http://cryptic-cliffs-32040.herokuapp.com/ Den Jinja2 Parser gibt es auch als Github Projekt https://github.com/qn7o/jinja2-live-parser für eine lokale Installation.

Categories
IBM WebSphere Application Server Java

Java unrestricted policy Dateien in IBM WebSphere als Standard

IBM wird in den zukünftigen Versionen des Websphere Application Servers die Java unrestricted policy files als default ausliefern. Die originale Ankündigung kann hier gelesen werden.

Damit entfällt beim Bauen der Archive für einen Server dieser Schritt in Zukunft. Für IBM Websphere 8.5 und 9.0 mit Java 8 gilt ist diese Voreinstellung ab Fixpack 10.

Categories
IBM WebSphere Application Server Middleware Security

XOR Passwort Encode/Decode für IBM Websphere XML Konfigurationsdateien

IBM Websphere speichert Passwörter der WebSphere Application Server Konfiguration in XML Dateien im Profilpfad der WAS Adminkonsole (IBM Integrated Solutions Console – ISC). Diese Passwörter sind nicht verschlüsselt, sondern nur per XOR kodiert. Da

a xor b xor b = a

gilt, kann ein XOR kodiertes Passwort auch wieder im Klartext ausgegeben werden. IBM liefert Werkzeuge für den Decode/Encode Vorgang gleich mit.

Um dies zu verdeutlichen, betrachte ich einen Passwordhash einer IBM WebSphere Application Server Zelle (security.xml). Die kodierten Passwörter können einfach gefunden werden:

grep xor security.xml

Vorgehensweise für Websphere 8.0 und 8.5 – Decoding
Zuerst in das Verzeichnis <WAS_HOME> wechseln. Von dort den Decoder Prozess ausführen:

java/bin/java -Djava.ext.dirs=./plugins:./lib com.ibm.ws.security.util.PasswordDecoder {xor}HDc6PDQZNjM6Hjw8OiwsfQ==

Das Passwort ist mit dem führenden “{xor}” zu übergeben.

Vorgehensweise für Websphere 9.0 – Decoding
Wie bei WAS 8.x Installationen in das Verzeichnis <WAS_HOME> wechseln. Von dort den Decoder Prozess starten, die Pfade für Java sind in WAS 9.0 unter Umständen abweichend (je nachdem, wie es installiert wurde). Ich habe es in Beispiel mit Java 8.0 aufgerufen:

java/8.0/bin/java -Djava.ext.dirs=./plugins:./lib com.ibm.ws.security.util.PasswordDecoder {xor}HDc6PDQZNjM6Hjw8OiwsfQ==

 

Der Zugriff auf die Konfigurationsdateien ist daher unbedingt besonders zu schützen!

Encoding
Der Prozess des Encodings ist durch Austauschen von PasswordDecoder durch PasswordEncoder möglich:

java/8.0/bin/java -Djava.ext.dirs=./plugins:./lib com.ibm.ws.security.util.PasswordEncoder CheckFileAccess!

 

Die Thematik wird auch von IBM auf developerworks diskutiert: devloperworks – Encrypting WebSphere Application Server system passwords