STRATO Linux VServer mit Webserver im Rettungssystem

Maintenance Seite

Ich kann den STRATO vServern in ein Rettungssystem starten, welches leider keinen Webserver enthält.
Das Rettungssystem ist Praktisch, da ich über dieses Alternative Betriebssystem an alle Daten die auf dem Server abgelegt sind gelangen kann, auch wenn mein selbst verwaltetes Betriessystem auf dem Server nicht mehr funktioniert. Die Besucher meiner Seite erfahren leider nicht das ich meinen Server grade warte.
Um den potentiellen besuchern meiner Seite jedoch zeigen zu können das meine Seite durchaus noch vorhanden, nur grade in einem Wartungsfenster ist, ist ein solcher sehr wünschenswert.

Der einfache versuch via „apt update && apt install lighttps“ führt jedoch leider zu ein paar nicht sehr aussagekräftigen Fehlermeldungen.

Es fehlen jedoch einfach nur ein paar Benutzer, genauer die Benutzer _apt, der Benutzer postfix und der Benutzer www-data.

adduser --quiet --gecos "" --no-create-home --disabled-password --disabled-login --ingroup nogroup --force-badname -uid 119 _apt
adduser --quiet --gecos "" --no-create-home --disabled-password --disabled-login --ingroup postfix -uid 111 postfix
adduser --quiet --gecos "" --no-create-home --disabled-password --disabled-login --ingroup www-data --uid 33 www-data

Im Anschluss kann der Webserver einfach installiert werden.:

apt update
apt -y install lighttpd php-cgi
lighttpd-enable-mod fastcgi

Im Anschluss bearbeite ich die Datei /etc/lighttpd/lighttpd.conf und füge am ende die folgenden 4 Zeilen an.:

url.rewrite = ( "" => "/maintenance.php" )
fastcgi.server = ( ".php" => ((
 "bin-path" => "/usr/bin/php-cgi",
 "socket" => "/tmp/php.sock"
)))

Die Raute # in der Zeile ‚#  „mod_rewrite“,‘ muss entfernt werden, so das die erste Zeile jedwede Anfragen an die Datei maintenance.php im Ordner /var/www/html/ umleiten kann.
Die verbleibenden drei Zeilen ermöglichen es dem Webserver PHP-Scripte auszuführen.

Die Datei /var/www/html/maintenance.php gibt in meinem Beispiel den HTTP StatusCode 503 (Vorübergehend nicht verfügbar; Server überlastet, ausgefallen oder in Wartung) und einen kurzen Wartungstext aus.:

<?php
if ( $_SERVER['SERVER_PROTOCOL'] === 'HTTP/1.1' )
 { $p = 'HTTP/1.1'; }else{ $p = 'HTTP/1.0'; }
header( $p.' 503 Service Unavailable', true, 503 );
header( 'Retry-After: 3600' );
?><!doctype html>
<title>Site Maintenance</title>
<style>
  body { text-align: center; padding: 150px; }
  h1 { font-size: 50px; }
  body { font: 20px Helvetica, sans-serif; color: #333; }
  article { display: block; text-align: left; width: 650px; margin: 0 auto; }
  a { color: #dc8100; text-decoration: none; }
  a:hover { color: #333; text-decoration: none; }
</style>

<article>
    <h1>We&rsquo;ll be back soon!</h1>
    <div>
        <p>Sorry for the inconvenience but we&rsquo;re performing some maintenance at the moment.</p>
        <p>we&rsquo;ll be back online shortly!</p>
        <p>&mdash; The Team</p>
    </div>
</article>

Zu guter letzt muss der Webserver nur noch neu gestartet werden, und es wird die Wartungsseite angfezeigt.

service lighttpd restart

git als static binary compilieren

GIT

Was ist eine „static binary“?

Während der Übersetzung eines Quellcodes in ein ausführbares Programm verknüpft der Compiler die ausführbare Datei des Programms, um später bei der Ausführung des Programms Arbeitsspeicher zu sparen, mit „shared dynamic libraries“.

Diese Bibliotheken sind eine Sammlung von Funktionen welche von mehreren Programmen geteilt verwendet werden um bestimmte Aufgaben zu zu erfüllen. Durch die gemeinsame Nutzung dieser Bibliotheken kann der Arbeitsspeicher des Computers geschont werden, da nur eine Kopie der Bibliothek für viele verschiedene Programme im Speicher geladen sein muss. Um ein unerwartetes Verhalten von Programmen zu vermeiden, ist es manchmal unumgänglich das Programm mit einer bestimmten Version einer Bibliothek zu Übersetzen. Auch um die Portabilität eines Programms zu verbessern ist es wichtig die Abhängigkeit vom vorhanden sein einer dynamischen Bibiothek zu vermeiden. In Linux Systemen sorgt ein Paketmanager dafür, dass Versionsabhängigkeiten korrekt erfüllt werden. Wenn Du auf einem Computer arbeitest über den Du keine Administrative Kontrolle besitzt kannst Du die Version der verwendeten Bibliothek nicht bestimmen oder eine aktualisiert verhindern.
Programme können, wenn sie mit „shared dynamic libraries“ übersetzt wurden nur auf andere Computer übertragen werden auf der, die gleiche Prozessorarchitektur und die gleichen Bibliotheken verfügbar sind.
Falls die Bibliotheken des Computers auf den das Programm übertragen wurde aktualisiert werden, eine Bibliothek entfernt wird oder eine der Bibliotheken auf dem Zielrechner werden kompromittiert oder durch bösartige Versionen ersetzt. Hier kommt das bauen einer „static binary“ ins Spiel.   Wie wird GIT als „static binary“ übersetzt?

in diesem Beispiel gehe ich davon aus das auf der NAS, entsprechend meiner Anleitung, bereits mit dem hier notwendigen Buildsystem ausgestattet wurde. Im Anschluss kann die entstehende GIT Binärdatei auf allen identischen ARM Prozessoren verwendet werden.
Die aktuellste GIT Version kann auf http://git-scm.com gefunden werden.

Die Folgenden 3 Schritte sind auszuführen:

1) Lade den GIT Quellcode herunter, entpacke die tar.gz-Datei und wechsle in das GIT Buildverzeichnis:

wget --no-check-certificate https://kernel.org/pub/software/scm/git/git-2.9.5.tar.gz
tar xzf git-2.9.5.tar.gz
cd git-2.9.5

2) Setze die Compilervariablen und konfiguriere ihn mittels ./configure. Hierbei kannst du ein  separates Verzeichnis zum übersetzen angeben.:

mkdir /usr/src/git-static
CHOST="armv6j-hardfloat-linux-gnueabi"
CFLAGS="-Os -march=arm1136jf-s -mfpu=vfp -mfloat-abi=hard -pipe -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}"
./configure --prefix=/usr/src/git-static CFLAGS="${CFLAGS} -static"

3) übersetze GIT:

make

…und installiere GIT in das Zielverzeichnis

make install

4) Prüfe anschließend das deine neue GIT-Version wie erwartet funktioniert

cd /usr/src/git-static
./git --version

Raspberry Pi: Animiertes Bootlogo (splash screen)

Ich suchte für meinen MAME-Retro-Arcasde Automaten nach einer Möglichkeit ein Bootlogo anzuzeigen, so das ersichtlich ist das der Automat noch startet. (und nicht etwa hängen geblieben ist)

Leider dauert das laden des Linux-Systems und des MAME mehrere Minuten auf dem Raspberry Pi, so das ein stehendes Bild wie ein abgestürztes System erscheinen. Die Linux Boot-Meldungen hingegen passen nicht zu einem Spielautomaten.

Ich persönlich verwende für meinen Spielautomaten ein statisches Bild, das MAME-Logo, vor welches ich einen loading spinner! gelegt habe.
Sehr schön für einen Spielautomaten sind auch animierte Charaktere aus klassischen Spielen, wie die Eule aus Apydia. Suche bei der Suchmaschine deine Wahl nach „animated gif sprites“ um einige zu finden.Agony (1992) Art & Magic / Psygnosis

Die Bootmeldungen können über die drei Einträge „consoleblank=0 loglevel=1 quiet“ in der Datei cmdline.txt im Verzeichnis /boot abgeschaltet werden.
Ebenfalls in der Datei cmdline.txt kann das Bootlogo, die Himbeeren die oben links erscheinen, mittels „logo.nologo“ abgeschaltet werden.
Mit dem Eintrag disable_splash=1 in der Datei config.txt im Ordner /boot schaltet Ihr auch noch das Regenbogen-Startbild des Raspberry Pi ab.

Splashscreen Werkzeuge wie FbiPlymouth oder FMI unterstützen leider keine Animationen. Das Werkzeug bannerd von Alexander Lukichev füllt genau diese Lücke und bietet die Möglichkeit eine Serie von BMP-Bildern als Animation wiederzugeben. (Die Letzte Aktualisierung des von bannerd ist leider aus dem September 2012)

Im Raspbian Repository ist bannerd aktuell leider nicht vorhanden, kann jedoch einfach aus den Quellen übersetzt werden.
Hierzu holen wir den Quellcode aus dem GIT-Repository und übersetzen es im Anschluss mittels make.:

git clone https://github.com/alukichev/bannerd.git
cd bannerd
make

Im Anschluss muss die entstandene Datei bannerd in den Ordner /usr/local/bin/ oder /bin kopiert werden, ausführbar gemacht werden sowie der Eigentümer und die Gruppe auf root geändert werden.

sudo cp bannerd /usr/local/bin/
sudo chown root:root /usr/local/bin/bannerd
sudo chmod 755 /usr/local/bin/bannerd

Als Bootanimation ist bei bannerd ausschließlich eine Sequenz von BMP Bildern möglich. Wenn die Boot-Animation bereits als Videodatei oder als animiertes Gif vorliegt kann diese mittels ffmpeg in eine Bildsequenz umgewandelt werden.

ffmpeg -i original_animation.gif %04d.bmp

Da mein Beispiel GIF eine Transparenz hat und ffmpeg leider automatisch weiß als Hintergrundfarbe bei der Umwandlung in Dateiformate ohne Apha Kanal.
Wenn Du eine andere Hintergrundfarbe als weiß benötigst können solche animierte GIFs leider nicht direkt umgewandelt werden.
Mit dem Umweg über PNG Bilder mit Alpha Transparenz können den BMPs auch andere Hintergundfarben gegeben werden.:

ffmpeg -i original_animation.gif %04d.png
mogrify -background black -flatten -format bmp *.png

Wenn das animierte GIF als kleine Animation in der unteren rechten Ecke des Bootbildes angezeigt werden soll können die Animationphasen mit folgenden Befehlen mit einem Hintergrundbild zusammengefügt werden. (Das Hintergrundbild wird im folgenden Beispiel mittels Imagemagic als leeres schwarzes Bild erzeugt.)

convert -size 800x480 xc:black hintergrund.jpg
wget https://loteks.de/wp-content/uploads/2017/10/agonyamiga.gif
ffmpeg -i agonyamiga.gif %04d.png
for f in *.png ; do composite -gravity southeast -geometry +25+25 "$f" hintergrund.jpg "${f%.png}.bmp" ; done
sudo mkdir /etc/bootanimation
sudo mv *.bmp /etc/bootanimation/
sudo chown root:root /etc/bootanimation -R

Nach dem wir jetzt den Dienst bannerd haben und die anzuzeigende Animation abgelegt haben brauchen wir noch einen systemd Service der im Bootvorgang bannerd startet.

der Service kann in Form der folgenden Datei /etc/systemd/system/bootlogo.service erzeugt werden:

[Unit]
Description=bootlogo
DefaultDependencies=no
After=local-fs.target

[Service]
ExecStart=/bin/sh -c '/usr/local/bin/bannerd -vD /etc/bootanimation/*.bmp'
StandardInput=tty
StandardOutput=tty

[Install]
WantedBy=sysinit.target

Jetzt muss der nrur Dienst noch aktualisiert werden.: sudo systemctl enable bootlogo
Das Bootlogo kann mit dem Befehl systemctl start bootlogo oder mit einem neustart des Computers getestet werden.

Neuer Linux Kernel für Raspberry Pi

Manchmal brauche ich einfach das eine oder andere Kernel Modul welches sich nicht im Vanilla Kernel meines Rasbian befindet, oder ich möchte unbedingt einige Module loswerden oder ich will einen aktuelleren linux Kernel.
Um eines oder alle diese Ziele zu erreichen muss ein neuer Linux Kernel für den Raspberry Pi angefertigt werden. Hier die Kurzanleitung wie dies in fünf einfach Schritten zu schaffen ist.:

1.) Linux Kernel Quellen herunterladen

Um den Aktuellen Kernel übersetzen zu können brauchen wir einige Module. Um diese zu Installieren nutzen wir apt-get install.:

sudo apt-get install bc git build-essential

Um den „aktuellen“ Linux Kernel zu bekommen holen wir über Git die Quellen:

git clone --depth=1 https://github.com/raspberrypi/linux

alternativ können wir auch einen aktuelleren Kernel (im Beispiel 4.5) holen lassen.:

git clone --depth=1 --branch=rpi-4.5.y https://github.com/raspberrypi/linux

und wechseln in das Installationsverzeichnis.

cd linux

2.) Default Konfiguration erstellen

Im Anschluss muss ich die default Linux Konfiguration für meinen Raspberry Pi erstellen, für Raspberry Pi 1 A oder B und das Compute Module:

KERNEL=kernel
make bcmrpi_defconfig

für den Raspberry Pi 2 geht dies über:

KERNEL=kernel7
make bcm2709_defconfig

3.) Kernel konfiguration anpassen (optional)

um die Konfiguration des Linux Kernels anzupassen bietet Linux die

make menuconfig

oder alternativ

make nconfig

4.) Kernel übersetzen

um den Kernel im Anschluss zu compilieren die folgenden Zeilen ausführen:

make zImage modules dtbs

5.) Kernel Installieren

sudo make modules_install
sudo cp arch/arm/boot/dts/*.dtb /boot/
sudo cp arch/arm/boot/dts/overlays/*.dtb* /boot/overlays/
sudo cp arch/arm/boot/dts/overlays/README /boot/overlays/
sudo scripts/mkknlimg arch/arm/boot/zImage /boot/$KERNEL.img

Wenn der Kernel einen abweichenden Namen erhalten soll kann in der Datei config.txt die Zeile „kernel“ für den verwendeten Kernel angepasst werden.:

kernel=meinKernel.img

Raspberry Pi 2 – Arch Linux Installation aus einem Linux System

Vorbereiten der SD-Karte. Ersetze sdX in den folgenden Schritten durch den entsprechenden Namen des Gerätes unter dem deine SD-Karte in Linux erschienen ist. (leicht über dmesg|tail direkt nach Anschluss der SD-Karte zu finden)

  1. Starte fdisk um die SD-Karte zu partitionieren:
    sudo –s # um alle folgenden Schritte als Benutzer root auszuführen
    fdisk /dev/
    sdX
  2. In der fdisk Eingabe lösche die alten Partitionen und erstelle die neuen:
    1. Der Befehl o löscht alle Partitionen auf der Karte.
    2. p zeigt alle vorhandenen Partitionen an. Es sollte keine mehr existieren
    3. Wähle n, für neue Partition, dan p für primäre Partition, im Anschluss 1 für die erste Partition, danach ENTER um den ersten Sektor zu bestätigen und +100M für den letzten Sektor.
    4. Im Anschluss t, danach c um den Typ der Partition auf „W95 FAT32 (LBA)“ zu setzen.
    5. Drücke n, dan p im Anschluss 2 für die zweite Partition dann ENTER zwei mal um sowohl den ersten als auch den letzten Sektor zu bestätigen.
    6. Schreibe die Partitionstabelle und verlasse das Programm mit w.
  3. Erstellen des ext4 Dateisystems:
    mkfs.ext4 /dev/sdX2
    mkdir /mnt/root
    mount /dev/sdX2 /mnt/root
  4. FAT-Dateisystem erstellen und mounten:
    mkfs.vfat /dev/sdX1
    mkdir /mnt/root/boot
    mount /dev/sdX1 /mnt/root/boot
  5. Lade die ArchLinux Distribution auf das root Dateisystem:
    wget http://archlinuxarm.org/os/ArchLinuxARM-rpi-2-latest.tar.gz
    tar -xpf ArchLinuxARM-rpi-2-latest.tar.gz -C /mnt/root
    sync
  6. Die beiden Partitionen unmounten:
    umount /mnt/root/boot /mnt/root

Jetzt ist die SD-Karte bereit für den Raspberry Pi. Nach dem Anschluss von Netzwerk und 5V-Stromversorgung startet er ArchLinux.
Eine Verbindung ist über angeschlossenen Monitor und Tastatur, SSH und Serielle Konsole möglich.
Der Benutzername des default Benutzers ist „alarm“ sein Passwort lautet „alarm“.
Das root-Password lautet „root“.

shellshock II (RPM-Paket erstellen)

In der chroot-Umgebung aus der ersten Anleitung kann auch direkt ein rpm Paket erstellen, welches eine saubere Installation der aktualisierten Bash ermöglicht.

Die Anleitung beginnt an Punkt 2 (2. Bash Quellen bereitstellen) der ersten Anleitung!

In der chroot-Umgebung des Build Systems einen Benutzer für den Paketbau anlegen:

chroot /mnt/chroot
adduser builder  && su builder && cd ~

Im Anschluß werden die für rpmbuild notwendigen Verzeichnisse, die drei Bash Konfigurations-Dateien .bashrc, .bash_profile, .bash_logout und die Specs-Datei für den rpm-Paketbau angelegt und die Bash Quellcodes sowie Patches heruntergeaden.:

mkdir -p ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}
cd ~/rpmbuild/SOURCES/
wget ftp://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
wget ftp://ftp.gnu.org/gnu/bash/bash-4.3-patches/ -m -nd
cat <<'EOF' > dot-bash_logout
# ~/.bash_logout: executed by bash(1) when login shell exits.

# when leaving the console clear the screen to increase privacy

if [ "$SHLVL" = 1 ]; then
[ -x /usr/bin/clear_console ] && /usr/bin/clear_console -q
fi
EOF
cat <<'EOF' > dot-bash_profile
# .bash_profile

# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi

# User specific environment and startup programs

PATH=$PATH:$HOME/bin

export PATH
EOF
cat <<'EOF' > dot-bashrc
# If not running interactively, don't do anything
[ -z "$PS1" ] && return

# don't put duplicate lines or lines starting with space in the history.
# See bash(1) for more options
HISTCONTROL=ignoreboth

# append to the history file, don't overwrite it
shopt -s histappend

# for setting history length see HISTSIZE and HISTFILESIZE in bash(1)
HISTSIZE=10000
HISTFILESIZE=20000

# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
shopt -s checkwinsize

# make less more friendly for non-text input files, see lesspipe(1)
[ -x /usr/bin/lesspipe ] && eval "$(SHELL=/bin/sh lesspipe)"

# set variable identifying the chroot you work in (used in the prompt below)
if [ -z "$debian_chroot" ] && [ -r /etc/debian_chroot ]; then
debian_chroot=$(cat /etc/debian_chroot)
fi

# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
xterm-color) color_prompt=yes;;
esac

# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt
#force_color_prompt=yes

if [ -n "$force_color_prompt" ]; then
if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
# We have color support; assume it's compliant with Ecma-48
# (ISO/IEC-6429). (Lack of such support is extremely rare, and such
# a case would tend to support setf rather than setaf.)
color_prompt=yes
else
color_prompt=
fi
fi

if [ "$color_prompt" = yes ]; then
PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
else
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
unset color_prompt force_color_prompt

# If this is an xterm set the title to user@host:dir
case "$TERM" in
xterm*|rxvt*)
PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
;;
*)
;;
esac

# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
alias ls='ls --color=auto'
#alias dir='dir --color=auto'
#alias vdir='vdir --color=auto'

alias grep='grep --color=auto'
alias fgrep='fgrep --color=auto'
alias egrep='egrep --color=auto'
fi

# some more ls aliases
alias ll='ls -alF'
alias la='ls -A'
alias l='ls -CF'

# Add an "alert" alias for long running commands. Use like so:
# sleep 10; alert
alias alert='notify-send --urgency=low -i "$([ $? = 0 ] && echo terminal || echo error)" "$(history|tail -n1|sed -e '\''s/^\s*[0-9]\+\s*//;s/[;&|]\s*alert$//'\'')"'

# Alias definitions.
# You may want to put all your additions into a separate file like
# ~/.bash_aliases, instead of adding them here directly.
# See /usr/share/doc/bash-doc/examples in the bash-doc package.

if [ -f ~/.bash_aliases ]; then
. ~/.bash_aliases
fi

# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
if [ -f /etc/bash_completion ] && ! shopt -oq posix; then
. /etc/bash_completion
fi

export LANG=de_DE.utf8
export LC_CTYPE=de_DE.UTF-8

test "$SSH_AUTH_SOCK" || exec ssh-agent $SHELL -c "ssh-add; exec $SHELL -login"
EOF
cd ~/rpmbuild/SPECS
cat < <'EOF' > bash.spec
# BASH spec File TEST
#%define beta_tag rc1
%define patchlevel .30
%define baseversion 4.3

# Build auch mit unpackaged files abschliessen
%define _unpackaged_files_terminate_build 0
%define _missing_doc_files_terminate_build 0

Version: %{baseversion}%{patchlevel}
Name: bash
Summary: The GNU Bourne Again shell
Release: 1%{?dist}
Group: System Environment/Shells
License: GPLv3+
Url: http://www.gnu.org/software/bash
Source0: ftp://ftp.gnu.org/gnu/bash/bash-%{baseversion}.tar.gz

Source1: dot-bashrc
Source2: dot-bash_profile
Source3: dot-bash_logout

# Official upstream patches
Patch001: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-001
Patch002: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-002
Patch003: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-003
Patch004: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-004
Patch005: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-005
Patch006: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-006
Patch007: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-007
Patch008: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-008
Patch009: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-009
Patch010: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-010
Patch011: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-011
Patch012: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-012
Patch013: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-013
Patch014: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-014
Patch015: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-015
Patch016: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-016
Patch017: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-017
Patch018: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-018
Patch019: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-019
Patch020: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-020
Patch021: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-021
Patch022: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-022
Patch023: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-023
Patch024: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-024
Patch025: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-025
Patch026: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-026
Patch027: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-027
Patch028: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-028
Patch029: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-029
Patch030: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-030

Requires(post): ncurses-libs
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

BuildRequires: ncurses-devel
BuildRequires: autoconf, gettext

%description
The GNU Bourne Again shell (Bash) is a shell or command language
interpreter that is compatible with the Bourne shell (sh). Bash
incorporates useful features from the Korn shell (ksh) and the C shell
(csh). Most sh scripts can be run by bash without modification.

%define pkgdocdir %{_datadir}/doc/%{name}-%{version}

%prep
#%setup -q -a 2
%setup -q -n %{name}-%{baseversion}

# Official upstream patches
%patch001 -p0 -b .001
%patch002 -p0 -b .002
%patch003 -p0 -b .003
%patch004 -p0 -b .004
%patch005 -p0 -b .005
%patch006 -p0 -b .006
%patch007 -p0 -b .007
%patch008 -p0 -b .008
%patch009 -p0 -b .009
%patch010 -p0 -b .010
%patch011 -p0 -b .011
%patch012 -p0 -b .012
%patch013 -p0 -b .013
%patch014 -p0 -b .014
%patch015 -p0 -b .015
%patch016 -p0 -b .016
%patch017 -p0 -b .017
%patch018 -p0 -b .018
%patch019 -p0 -b .019
%patch020 -p0 -b .020
%patch021 -p0 -b .021
%patch022 -p0 -b .022
%patch023 -p0 -b .023
%patch024 -p0 -b .024
%patch025 -p0 -b .025
%patch026 -p0 -b .026
%patch027 -p0 -b .027
%patch028 -p0 -b .028
%patch029 -p0 -b .029
%patch030 -p0 -b .030

echo %{version} > _distribution
echo %{release} > _patchlevel

%build
autoconf
%configure --with-bash-malloc=no --with-afs --with-installed-readline
make "CPPFLAGS=-D_GNU_SOURCE -DRECYCLES_PIDS `getconf LFS_CFLAGS`"
%check
make check
strip bash
strip bashversion

%install
rm -rf $RPM_BUILD_ROOT

if [ -e autoconf ]; then
  export PATH=.:$PATH
fi

# Fix bug #83776
perl -pi -e 's,bashref\.info,bash.info,' doc/bashref.info

make DESTDIR=$RPM_BUILD_ROOT install

mkdir -p $RPM_BUILD_ROOT/etc

# Not for printf, true and false (conflict with coreutils)
rm -f $RPM_BUILD_ROOT/%{_mandir}/man1/printf.1
rm -f $RPM_BUILD_ROOT/%{_mandir}/man1/true.1
rm -f $RPM_BUILD_ROOT/%{_mandir}/man1/false.1

pushd $RPM_BUILD_ROOT
mkdir ./bin
mv ./usr/bin/bash ./bin
ln -sf bash ./bin/sh
rm -f .%{_infodir}/dir
popd
mkdir -p $RPM_BUILD_ROOT/etc/skel
install -c -m644 %SOURCE1 $RPM_BUILD_ROOT/etc/skel/.bashrc
install -c -m644 %SOURCE2 $RPM_BUILD_ROOT/etc/skel/.bash_profile
install -c -m644 %SOURCE3 $RPM_BUILD_ROOT/etc/skel/.bash_logout
LONG_BIT=$(getconf LONG_BIT)
mv $RPM_BUILD_ROOT%{_bindir}/bashbug \
   $RPM_BUILD_ROOT%{_bindir}/bashbug-"${LONG_BIT}"

%find_lang %{name}

# lua-code von Jesse Keating  so das keine Externen Abhängigkeiten benötigt werden.
# lua-Code von Ignacio Vazquez-Abrams
%post -p 
bashfound = false;
shfound = false;

f = io.open("/etc/shells", "r");
if f == nil
then
  f = io.open("/etc/shells", "w");
else
  repeat
    t = f:read();
    if t == "/bin/bash"
    then
      bashfound = true;
    end
    if t == "/bin/sh"
    then
      shfound = true;
    end
  until t == nil;
end
f:close()

f = io.open("/etc/shells", "a");
if not bashfound
then
  f:write("/bin/bash\n")
end
if not shfound
then
  f:write("/bin/sh\n")
end
f:close()

%postun
if [ "$1" = 0 ]; then
    /bin/grep -v '^/bin/bash$' < /etc/shells | \       /bin/grep -v '^/bin/sh$' > /etc/shells.new
    /bin/mv /etc/shells.new /etc/shells
fi

%files -f %{name}.lang
%defattr(-,root,root)
%config(noreplace) /etc/skel/.b*
/bin/sh
/bin/bash
%attr(0755,root,root) %{_bindir}/bashbug-*
EOF

Die bash.spec-Datei enthält die Konfigutarion des Paketes sowie die bei der Installation und deinstallation notwendigen Scripte. Die Vorliegende SPECS Datei ist eine bearbeitung der Original Quelle von Fedora Core 12, welche ich für die aktuelle BASH angepasst habe.

Jetzt kann mit rpmbuild das Paket erstellt werden, welches direkt im Anschluss mit rpm Installiert werden kann. Das alte Bash Paket wird hierbei durch das neue Paket ersetzt.

rpmbuild -ba  bash.spec
rpm -U --force --replacefiles /mnt/chroot/home/builder/rpmbuild/RPMS/armv6l/bash-4.3.30-1.fc12.armv6l.rpm

Das aus diesem Tutorial entstehende Bash-Binary und RPM-Datei zur Installation

squashfs Image einer Linux Distribution über Grub starten

Dies ist eine „Kurzanleitung“, wie ein squashfs Image über Grub zu starten. Ich gehe davon aus, das Grub installiert ist und das du das <LinuxBootCD>.iso Image besitzt.

Um unser Ziel zu erreichen kopieren wir einige Dateien aus dem ISO Image und schaffen einen Grub Eintrag.

$ sudo su
# mkdir /system
# mkdir loopmount
# mount -o loop .iso loopmount
# cp -a loopmount/system/vmlinuz1 /system
# cp -a loopmount/system/initrd1.img /system
# cp -a loopmount/system/filesystem.squashfs /system
# cp -a loopmount/system/filesystem.packages /system
# umount loopmount
# ls /system
filesystem.packages filesystem.squashfs initrd1.img memtest vmlinuz1

Jetzt sind alle benötigten Daten kopiert, es folgt die GRUB Einrichtung.

# vi /etc/grub.d/41_CB_squashfs

#!/bin/sh
exec tail -n +3 $0
menuentry 'Boote das squashfs Linux Image' --class debian --class gnu-linux --class gnu --class os {
insmod part_msdos
insmod ext2
set root='(hd0,msdos1)'
linux /system/vmlinuz1 boot=live live-media-path=/system splash vga=791 config quiet noprompt
initrd /system/initrd1.img
}

# update-grub

Dies ist bereits der gesammte Prozess. Nach der aktuelisierung der Grub Konfiguration via update-grub ist existiert der neue Boot-Eintrag.

Zeit neu zu booten und im Grub den neuen Boot-Eintrag zu wählen.

Ich mag diese Art der „Installation“, da der Boot-Vorgang dank squashfs sehr schnell und vor ungewollten Veränderungen geschützt ist. 😉

X-server-minimal

Die X-Server Grundinstallation

$ aptitude install xserver-xorg-core

zusätzlich muss noch eine Terminal Emulation, einen Window Manager und gegebenen falls das Programm für den Ziffernblock manuell installiert werden.
Terminal Emulationen:
– xterm (1180kB)
– multi-aterm (188kB) mit Tabs
– xvt (139kB)

Window Manager:
– icewm
– fluxbox oder blackbox

Um den Ziffernblock unter X.ORG zu aktivieren wird das folgende Programm benötigt, es ist für Notebooks, Netbooks nicht sinvoll und wird auch bei einer KDE, gnome oder xfce Installation unnötig.
– numlockx

Xserver starten

Um den Server manuell zu starteten wird folgendes in die Schell eingegeben:
$ startx icewm (in dem angegeben beispiel wird icewm gestartet!)

Komfortabler geht es mit einem Displaymanager wie xdm (X Display Manager). Wird ein solcher installiert, bootet der Rechner bis zu einem grafischen Login um dann den Windowmanager / die Deskop Umgebung zu starten.

Displaymanager

– xdm (ca 1MB)
– gdm (ca 9MB + Gnomelibs)
– kdm (ca 1MB + KDELibs)
– login.app (ca 1MB)
– slim (ca 1MB)
– wdm (ca 1MB)

Window Manager

$ aptitude install xserver-xorg-core icewm

Die Empfehlung aus „Xserver-minimal“ und „Displaymanager“:
$ aptitude install xserver-xorg-core icewm numlockx multi-aterm wdm

ergeben eine einfach zu nutzende grafische Oberfläche.
Eine Liste von Window Managern, die in debian enthalten sind, befindet sich im [„SoftwareFinder/GUI“].
Gedanken und Konfigurationsdateien für einen leichtgewichtigen Desktop (engl)

Desktop Umgebungen

KDE minimal

$ aptitude install xserver-xorg-core kdebase kdm
– Platzverbrauch durch diese Installation(zusätzlich zur Basisinstallation): 103MB + Sprachunterstützung (24MB)
– Arbeitsspeicherverbrauch durch diese Installation: ?
– Windowmanager ist enthalten: kwin
– kdm kann auch weggelassen werden wenn man einen anderen(oder keinen) Displaymanager nutzen möchte.
– kde-i18n-de für die deusche Tastaturunterstützung

Gnome minimal

$ aptitude install xserver-xorg-core gnome-core gdm
– Platzverbrauch durch diese Installation(zusätzlich zur Basisinstallation): 157MB
– Arbeitsspeicherverbrauch durch diese Installation: ?
– Windowmanager ist enthalten: metacity
– gdm oder anderen, oder keinen Displaymanager nutzen

XFCE minimal

$ aptitude install xserver-xorg-core xfce4 gdm
– Platzverbrauch durch diese Installation zusätzlich: 81MB
– RAM nutzung durch diese Installation: ~ 80 MB
– Windowmanager ist enthalten: xfwm
– gdm oder anderen, oder keinen Displaymanager nutzen

Schriften

Anwendungen welche GTK1 benutzen (zum Beisspiel xmms, emelfm) haben nach der Installation ohne eines der Folgenden Pakete unlesbare Schriften. Je nach eingestellter Auflösung:
– xfonts-100dpi-transcoded (ca 12MB)
– xfonts-75dpi-transcoded (ca 10MB)
– xfonts-base-transcoded (ca 2MB)