Die erste Frage die einem aufkommt ist: “Wozu brauche ich Ruby Gems als Apt Pakete?”. Nach kurzer Zeit fand ich heraus wozu. Die Ruby Pakete enthalten in Debian sind veraltet oder gar nicht erst vorhanden. Bei Ubuntu Hardy ist die Auswahl ebenfalls sehr gering. Auf meiner Debian Lenny Installation war von den Debianern sogar Rubygems in der Funktionalität eingeschränkt. Dies wird einem sogar schriftlich vorgehalten:

gem update --system is disabled on Debian. RubyGems can be updated using the official Debian repositories by aptitude or apt-get.

Das manuelle installieren / kompilieren von Paketen ist ein großer Zeitaufwand. Glücklicherweise fand ich einen Service der Debian Pakete von einem allen relevanten Gem Paketen anbietet. Die Debgem Kurzbeschreibung von der eigenen Webseite:

Apt is the package management system of choice for Debian users. Historically, only a very limited number of Ruby programs and libraries are packaged for Debian and installable through Apt. Instead, most Ruby programs and libraries are installed through RubyGems, a separate package management system created specifically for Ruby.

DebGem provides an Apt repository for Ruby programs and libraries which are currently available as gems. Debian users can now manage all their Ruby software through a single, centralized package manager – Apt – thereby making system administration a joy again!

Ich nutze diesen Service derzeit für Ruby 1.8 auf meinem Debian Lenny System und bin vollsten zufrieden damit. Der Haken an der Sache ist, das Debgem nur während der Beta Phase kostenlos bleiben wird. Es bleibt zu hoffen das die Gems bis dahin besser in Debian / Ruby 1.8 integriert sind.

INFO: Beim compilieren von Ruby 1.9.* in der neusten Version sollte das Problem nicht mehr bestehen.

Keine Kommentare »
 

Im heise.de Forum habe ich einen unglaublich guten Foren Beitrag gefunden. Für mich die beste Web Story des Januar 2011. Der Beitrag wurde als Antwort auf die News Meldung “Eclipse bekommt ein Browser-Interface“. Der Beitrags Ersteller scheint sich über die mangelnde Performance von Eclipse zu ärgern.

Traten in der bisherigen Version teilweise noch Situationen auf, wo
einem Klick relativ zeitnahe eine Aktion folgte, so stellen die
Entwickler klar “Dieses Problem wird mit der nächsten Version nicht
mehr auftreten!”

Nach reiflicher Überlegung erwies sich das Client<->Server Konzept
von Unix als die tauglichste Möglichkeit dies zu bewerkstelligen, da
mit der Ankündigung sich in zukünftigen Linux-Modellen von diesem
Konzept Abstand zu nehmen, somit die benötigte Verzögerung als
bewiesen gilt. Da Unix/Linux allerdings in hochperformanten C-Code
geschrieben wurde, kann der Code nicht einfach so übernommen werden,
da die Gefahr von akzeptabler Geschwindigkeit bestehen könnte.
Sicherheitshalber wechselt daher das Eclipse Projekt von dem
mittlerweile auch viel zu performanten Java auf JavaScript, dass mit
seiner ca. 18-fach langsameren Ausführungsgeschwindigkeit endlich das
gewünschte Look&Feel wieder herzustellen vermag.

Die Entwickler kündigten zudem an, die neue Oberfläche gründlich auf
eventuelle Reaktionszeiten zu testen und im Zweifelsfrei noch unnütze
aber sehr hübsche Animationen hinzuzufügen, um eventuellen
Stresssituationen am Arbeitsplatz entgegen zu wirken. Da die
Entwickler den aktuellen Code zur IDE in selbiger schreiben um von
eventuellen Abstürzen mit darauf folgendem Totalverlust des Codes zu
profitieren, wird ein Release etwa Mitte 2034 erwartet.

Geschrieben von Two am 12.01.2011 im Thread “Eclipse Entwickler finden Möglichkeit die IDE noch langsamer zu machen“. Vielen Dank für deinen Post Two.

Keine Kommentare »
 

Onlive Cloud Gaming Kritik

3D Spiele auf dem alters schwachen Laptop oder mit Hilfe einer kleines Endgerätes, für 99 Euro, im Zusammenhang mit einem Fernsehgerät spielen. Die Kosten für ein “Full PlayPass” belaufen sich dabei je nach Spiel und Spielzeit auf Kosten zwischen vier und 40 Euro.

Der Onlive Kunde muss sich keine teure Hardware anschaffen und die Spiele Hersteller haben durch den Onlive Dienst keine Probleme mit Raubkopierern mehr. Onlive hört sich für alle Beteiligten nach einem guten Angebot an.

Wo ist der Haken?

Das kleinste Übel – Internetzwang
An Orten ohne Internetanbindung kann nicht gespielt werden. Es würden Kosten entstehen, wenn man nicht sowieso schon online wäre.

Der Ping
Der Ping ist laut Foren Aussagen noch zu hoch (kurz: hoher Ping = schlecht). Dadurch laufen die Spiele nicht flüssig. Die Internet Anschlüsse der heutigen Zeit liefern dem Anschein nach nich genug Leistung. Nicht jeder Spieler wohnt neben einem Rechenzentrum. ):

Modding
Das Spiel wird in der Onlive Cloud gespielt. Der Client sendet nur die Kommados zur Steuerung des Spiels und empfängt Bildaten. Das Verändern oder Erweitern von Spielinhalten wäre nicht mehr möglich, so wie es heute schon bei allen Videospielkonsolen der Fall ist.

Privatsphäre
Das Spiel-Verhalten der Spieler kann und wird protokolliert werden.

Onlive “the evil company” Monopol – Patent beantragt
Onlive versucht sich laut golem.de durch das Beantragen von Patenten eine Monopolstellung im Bereich Cloud Gaming zu verschaffen. Sollte sich Onlive durchsetzen wird die Firma bestimmen was, wer, womit gespielt / entwickelt wird.

Mögliche Spätfolge: keine Games außerhalb der Cloud
Das Aussterben der Spiele auf dem Rechner Zuhause wird eine Folge des Cloud Gamings sein, wenn es sich durchsetzt.

Persönlich würde ich von solch einem Dienst die Finger lassen. Ob sich Cloud Gaming durchsetzt entscheidet die Spielergemeinde.

Keine Kommentare »
 

Auf heise.de habe ich am Tag nach dem Bemerken des Einbruchs (Bemerkt am: 01.12.2010) gelesen, das die offiziellen ProFTPD FTP Quellen seit dem 28.11.2010 mit einem Backdoor verseucht seien. Laut heise online soll die Infektion des Quellcodes über eine ungepatchte Sicherheitslücke Lücke im SQL-Modul in ProFTPD selbst verseucht worden seien. Was für eine Ironie. 🙂

Ich wusste mein Server ist nicht infiziert da ich mein System aus den Debian Paketquellen pflege und in darin niemals derart aktuelle Pakete enthalten sind. Dennoch wollte ich mehr darüber wissen. Auf der ProFTPD Projektseite fand ich eine News Meldung.

The ProFTPD Project team is sorry to announce that the Project’s main FTP server, as well as all of the mirror servers, have carried compromised versions of the ProFTPD 1.3.3c source code, from the November 28 2010 to December 2 2010. All users who run versions of ProFTPD which have been downloaded and compiled in this time window are strongly advised to check their systems for security compromises and install unmodified versions of ProFTPD.

To verify the integrity of your source files, use the PGP signatures which can be found here as well as on the FTP servers.

The source code in CVS was not affected.

CVS Benutzer müssen sich laut ProFTPD Team eigenen Angaben keine Sorgen machen. Anwender die die FTP Quellen benutzt haben sollten prüfen ob deine heruntergeladene Versionen des ProFTPD Quellcodes gültige PGP Signaturen aufweisen. (ProFTPD PGP Signaturen)

ProFTPD sollte normalerweise nicht als Prozess des Benuters root laufen. In wie weit das für den root Zugang über den Backdoor eine Rolle spielt weiß ich nicht. In kombination mit einem verwundbaren Kernel durch das “privilege escalation” Exploit der selben Gruppe wäre dies kein Hindernis. Mehr dazu hier.

Um das Aufspüren von infizierten Servern zu erleichtern habe ich ein Scanner Script “verfasst”. Wie du an der Shebang und der Syntax erkennst handelt es sich um ein Ruby Script.

#! /usr/bin/ruby -w
 
require 'net/ftp'
require 'timeout'
 
##
## Validate and split IP address 
##
def explodeip(ip)	
	if 5 == len = (ip = ip.match('^(d{1,3}).(d{1,3}).(d{1,3}).(d{1,3})$').to_a).length
		i = 1		
		4.times do
			ip[i] = ip[i].to_i()
			i = i + 1
		end
		return ip
	else
		return false
	end
end
 
##
## Check FTP host for infection
##
def checkinfect(ip)
	begin
		timeout(3) do
     		ftp = Net::FTP.new(ip)
			puts ip+': connected'
			begin
				ftp.sendcmd('help ACIDBITCHEZ')				
				puts ip+': infected'
			rescue Net::FTPPermError
				puts ip+': clean'
			ensure
				ftp.close()
			end
		end		
	rescue Timeout::Error
		puts ip+': timeout'
	rescue Errno::ECONNREFUSED
		puts ip+': connection refused'
	rescue Errno::EHOSTUNREACH
		## Maybe you wan't to google?
	end	
end
 
##
## Script info
##
if !ARGV[0].is_a?(String)
	puts '# ACIDBITCHEZ ProFTPD backdoor scanner'
	puts '# Usage: ./ACIDBITCHEZ_ftpscanner <ip adress> || <start ip> <end ip>'
	puts '# More: http://www.monkey-business.biz/1211/proftpd-acidbitchez-backdoor-scanner/'	
	Process.exit()
end
 
if ip1 = explodeip(ARGV[0])
	if ARGV[1].is_a?(String)
 
		##
		## Cycle trough IP's
		##
		if ip2 = explodeip(ARGV[1])
			while ip1[1] <= ip2[1]
				while ip1[2] <= ip2[2]								
					while ip1[3] <= ip2[3]					
						while ip1[4] <= ip2[4]							
							checkinfect(ip1[1].to_s()+'.'+ip1[2].to_s()+'.'+ip1[3].to_s()+'.'+ip1[4].to_s())
							ip1[4] = ip1[4] + 1
						end
						ip1[4] = 0
						ip1[3] = ip1[3] + 1							
					end
					ip1[3] = 0
					ip1[2] = ip1[2] + 1
				end
				ip1[2] = 0
				ip1[1] = ip1[1] + 1
			end
		else			
			puts '# Second IP adress not valid'
		end
 
	##
	## Check single IP
	##
	else
		checkinfect(ip1[0])	
	end
else
	puts '# IP adress not valid'
end

Das Script läuft nicht ansynchron / in Threads. Zusätzlich wird auch versucht IP Adressen zu scannen die nicht existieren können. Dadurch ist das Script sehr ineffizient. Das liegt daran das du damit nicht das ganze Internet scannen sollst. 😉

Mehr zum Thema:

Keine Kommentare »
 

Dinge die jeder an den Linux Distributionen liebt. Man benötig ein Programm und wie soll es auch anders sein, es funktioniert ohne Gebastel nicht. Der Installationsversuch des Frostwire Paketes von frostwire.com bringt folgendes zu tage:

dpkg: Fehler beim Bearbeiten von frostwire-4.21.1.i586.deb (--install):
Paket-Architektur (i386) passt nicht zum System (amd64)

Was für ein Glück das ich Java schon installiert hatte. 🙂
Das deb Paket auf der Webseite ist leider nicht für AMD64 “verpackt”. Die Prozessor Architektur spielt jedoch keine Rolle da Frostwire ein Java Programm ist. Die kurze Zeile

dpkg -i --force-architecture <PAKETNAME>.i586.deb

sollte das Problem lösen und den P2P Client installieren.

Keine Kommentare »
 

Das Beenden bzw. killen von Prozessen unter Linux / Unixoiden Systemen erfolgt in der Regel über das kill-Kommando in der Konsole. Bevor dieses Kommando zum “killen” des Prozessen benutzbar ist muss jedoch die Prozess ID ermittelt werden. Für das ermitteln der Prozess ID empfehle ich die Konsolen-Kommando Kombination:

ps aux | grep <PROZESSNAME>

<PROZESSNAME> ist mit dem Prozess Name zu ersetzen. Beispielsweise “apache”. Das “apache” Beispiel beschert mir auf einem Server diese Ausgabe:

www-data 18148  0.0  0.1 232000  8664 ?        S    Nov18   0:00 /usr/sbin/apache2 -k start
www-data 18158  0.0  0.1 232000  8688 ?        S    Nov18   0:00 /usr/sbin/apache2 -k start

Es ist auch möglich, sofern der genaue Prozessename bekannt ist, das Kommando “pidof” zu nutzen.

pidof <PROZESSNAME>

Der Output zu diesem Befehl enthält die Prozess ID’s oder die Prozess ID je nach Anzahl der laufenden Prozesse mit dem selben Namen.

8664 8688

Der zweite Schritt ist das eigentliche Beenden des Prozesses mit Hilfe des Kommandos kill.

kill <PROZESSID> <PROZESSID>

Prozess ID’s können mit einem Leerzeichen separiert angegeben werden. Sollte sich auf diesem Wege ein Prozess nicht beenden lassen kann mit der Option “-9” des Befehls kill entgegen gewirkt werden.

kill -9 <PROZESSID>

In diesem Fall wird der Prozess “hart” beendet. Es können ebenfalls mehrere ID’s mit einem Leerzeichen separiert werden.
Eine andere Art mehrere Prozesse auf einen Streich zu terminieren stellt der Befehl killall da.

killall -i <PROZESSNAME>

Der Parameter “-i” sorgt dafür das vor dem Beenden jedes Prozesses nochmals nachgefragt wird ob man ihn wirklich beenden möchte. Weitere wichtige Optionen sind die Befehle:

  • -u <UNIXUSERID> beendet die Prozesse des gewählen UNIX Benutzers
  • -g <PROZESSGRUPPENID> beendet die Prozesse der gewählten Prozessgruppe

Die Möglichkeit mehrere Prozesse mit einem Befehl zu beenden hat mir persönlich oft weitergeholfen als Server Dienste am spinnen waren. Schönes Wochenende. 😉

EDIT: Beachte das du zum killen einiger Prozesse als root angemeldet sein musst.

Keine Kommentare »