PeakSpray & IT

See how easy it is to auto deploy a virtual Maschine with Foreman and Puppet in a basic Szenario …

in den letzten Stunden habe ich mir mal owncloud angeschaut.
Hier eine kleine Anleitung zur Installation.

# dotdeb Paketquellen und Key adden

echo ‘deb http://packages.dotdeb.org squeeze all’ >> /etc/apt/sources.list
echo ‘deb-src http://packages.dotdeb.org squeeze all’ >> /etc/apt/sources.list

wget -O – http://www.dotdeb.org/dotdeb.gpg | apt-key add -

apt-get update

# Pakete installieren

apt-get install nginx
apt-get install php5-fpm
apt-get install php5-sqlite libcurl3 libcurl4-openssl-dev php5-curl php5-gd php5-common mp3info curl zip

# PHP Werte den eigenen Bedürfnissen anpassen

root@owncloud:~# cat /etc/php5/fpm/php.ini |grep 1024M
memory_limit = 1024M
post_max_size = 1024M
upload_max_filesize = 1024M

root@owncloud:~# /etc/init.d/php5-fpm restart
Restarting PHP5 FastCGI Process Manager: php5-fpm.

# vhost anlegen

root@owncloud:~# cat /etc/nginx/sites-available/owncloud
server {
listen 80;
server_name owncloud.meinedomaine.tld;
root /var/www/owncloud;

# This is to avoid a “Request Entity Too Large” error
client_max_body_size 1000M;
index index.php index.html index.htm;

dav_methods PUT DELETE MKCOL COPY MOVE;
create_full_put_path on;
dav_access user:rw group:rw all:r;

location = /favicon.ico {
log_not_found off;
access_log off;
expires max;
}

location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}

location ~ /\. {
deny all;
access_log off;
log_not_found off;
}

location / {
index index.php;
try_files $uri $uri/ @webdav;
}

location @webdav {
fastcgi_split_path_info ^(.+.php)(/.+)$;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include /etc/nginx/fastcgi_params;
#fastcgi_param HTTPS on;
fastcgi_pass 127.0.0.1:9000;
}

location ~ .php$ {
try_files $uri =404;
include /etc/nginx/fastcgi_params;
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_index index.php;
}
}

# nginx vhost aktivieren

root@owncloud:/# ngxensite owncloud
Site owncloud installed; run invoke-rc.d nginx reload to enable.
root@owncloud:/# /etc/init.d/nginx reload
Reloading nginx configuration: nginx.

Jetzt den browser öffnen und owncloud begrüßt Sie mit der Aufforderung einen Administrativen User samt Passwort fest zu legen.

Jeden morgen wenn ich ins Büro komme und mich im Foreman frontend einlogge sehe ich einige Hosts die “out of sync” sind! Das Problem besteht schon etwas länger aber bisher war ich zu faul um nach einer Lösung zu suchen.
Aktuell läuft diese Version

root@puppet:~# dpkg -l |grep puppet
ii facter 1.6.9-1puppetlabs1 Ruby module for collecting simple facts about a host operating system
ii puppet 2.7.14-1puppetlabs1 Centralized configuration management – agent startup and compatibility scripts
ii puppet-common 2.7.14-1puppetlabs1 Centralized configuration management
ii puppetmaster 2.7.14-1puppetlabs1 Centralized configuration management – master startup and compatibility scripts
ii puppetmaster-common 2.7.14-1puppetlabs1 Puppet master common scripts
ii vim-puppet 2.7.14-1puppetlabs1 syntax highlighting for puppet manifests in vim

Allerdings besteht dieses Problem schon seit längerem und tritt am liebsten auf VMWare virtualisierte Systeme auf! Da es mittlerweile viel zu viele Hosts sind um sich auf jedem System einzuloggen, und dort den agent zu restarten, hier meine Lösung die ich mit puppet verteile

root@puppet:~# cat /etc/puppet/modules/puppetfix/manifests/init.pp
class puppetfix{
file { “/etc/cron.d/puppetfix”:
owner => “root”,
group => “root”,
mode => 644,
source => “puppet:///modules/puppetfix/puppetfix”,
}
service { cron:
ensure => running,
hasrestart => true,
subscribe => File["/etc/cron.d/puppetfix"],
}

}

root@puppet:~# cat /etc/puppet/modules/puppetfix/files/puppetfix
##################################################
# Default distributed by Puppet #
# #
# DO NOT EDIT MANUALLY – WILL BE OVERWRITTEN #
##################################################

*/15 * * * * nobody /bin/echo ” | nc -w1 localhost 8139

Puppet hat nun unter /etc/cron.d/ die Datei puppetfix angelegt und den crond restartet.

DIRTY! aber sehr wirksam – seitdem gibt es keine sterbenden Agents mehr *freu*

jaja wer kennt diese Fehlermeldung nicht?

Error: Could not stat() command file ‘/var/external commands/lib/nagios3/rw/nagios.cmd’!

Dieses mal schreibe ich es mir aber auf – im Debian style natürlich.

root@monitoring:~# cat /etc/nagios3/nagios.cfg |grep check_external_commands
check_external_commands=1

Damit das ganze auch Update resistent konfiguriert ist:

root@monitoring:~# /etc/init.d/nagios3 stop
root@monitoring:~# dpkg-statoverride –-update –-add nagios www-data 2710 /var/lib/nagios3/rw
root@monitoring:~# dpkg-statoverride –-update –-add nagios nagios 751 /var/lib/nagios3
root@monitoring:~# /etc/init.d/nagios3 start

jaja die auth.log sieht manchmal schon etwas voll aus bei den ganzen SSH Bruteforce Angriffen.
Was kann man machen? Portknocking?

Der SSH Port ist so lange zu bis eine bestimmte reinfolge an tcpflags abgeschickt wurde.
Bei der richtigen rein folge innerhalb des richtigen Zeitabstandes, wird der SSH Port eine weile geöffnet für die “anklopfende” IP Adresse …

Installieren und konfigurieren – geht sehr schnell …

# apt-get install knockd

Starten

# nano /etc/default/knockd

und ändern in

START_KNOCKD=1

Konfigurieren

# nano /etc/knockd.conf

[openSSH]
sequence = 1357,8653,7689
seq_timeout = 15
start_command = /sbin/iptables -A INPUT -s %IP% -p tcp –dport 22 -j ACCEPT
tcpflags = syn
cmd_timeout = 30
stop_command = /sbin/iptables -D INPUT -s %IP% -p tcp –dport 22 -j ACCEPT

Restart

# /etc/init.d/knockd restart

FERTIG!

Port öffnen unter Linux

# knock 1357 8653 7689
# ssh root@hostname

Port öffnen unter Windows —> KnockKnock

Bei der Nutzung von Delay pools in Squid 3.1 unter Debian Squeeze z.bsp so

…
delay_pools 3

#delay pool 0.5M
delay_class 2 2
delay_access 2 allow zone_1
delay_access 2 allow zone_2
delay_access 2 deny all
delay_parameters 2 16000/65536 -1/-1

#delay pool 5M
delay_class 1 2
delay_access 1 allow zone_3
delay_access 1 deny all
delay_parameters 1 80000/5242880 -1/-1

#delay pool 1M
delay_class 1 2
delay_access 1 allow zone_4
delay_parameters 1 131072/131072 -1/-1
#no_cache deny all
…

tritt häufiger (mehrmals Täglich je nach Auslastung) mal die folgende Fehlermeldung auf

2012/01/26 14:40:27| TunnelStateData::Connection::error: FD 217: read/write failure: (32) Broken pipe
2012/01/26 15:19:11| Preparing for shutdown after 4947583 requests

mit dem Resultat, dass der Squid seinen Dienst quittiert!!!

Ich habe echt alles versucht aber die einzige Lösung war ein Downgrade auf Squid 2.7 – danach ist das Problem nie wieder aufgetreten.

Reproduzieren kann man das ganze so:

Squid 3.1.1 utilizing cpu (near 100%) when client using CONNECT & hitting delay pool.

How to reproduce:

1. Install squid 3.1.1
2. Add delay pool to specific host.
3. Using CONNECT to download any file from this host.
4. See cpu utilization on proxy when download in progress.

Foreman sammelt mir alle nötigen Facts von unseren Systemen.
Gerade kam die Anforderung eine Paketeliste zu sammeln damit Ireport diese später ausgeben kann.
Ireport nutzt bei uns die Datenbank von foreman.

Das ganze ist wirklich sehr einfach:

root@client1:~# cat /usr/lib/ruby/1.8/facter/packages.rb
# packages.rb

Facter.add(“pakete”) do
setcode do
Facter::Util::Resolution.exec(“dpkg -l | grep ^ii | awk ‘{print $2, $3}’”).chomp
end
end

Sieht dann so aus:

root@client1:~# facter pakete
acpi 1.5-2
acpi-support-base 0.137-5
acpid 1:2.0.7-1squeeze3
adduser 3.112+nmu2
apt 0.8.10.3+squeeze1
apt-utils 0.8.10.3+squeeze1
aptitude 0.6.3-3.2+squeeze1
aspell 0.60.6-4
aspell-de 20091006-4.2
aspell-de-alt 1:2-26
augeas-lenses 0.7.2-1
base-files 6.0squeeze4
….
….
….