Nautilus ist der Dateimanager der Desktop-Umgebung GNOME, der standardmäßig nach einer Neuinstallation von Ubuntu 10/10 benutzt wird.
Dabei fällt auf, dass Nautilus üblicherweise Verzeichnisse im Browser-Modus darstellt. In diesem Modus wird die Adressleiste in Form von Navigationsknöpfen angezeigt.
Diese Art der Darstellung ist meiner Meinung nach etwas ungeschickt, da eine direkte Eingabe von Pfaden wesentlich schneller von der Hand geht, als sich durch diese Pfade klicken zu müssen.
Zwar ist es möglich die Leiste mittels Strg + L umzuschalten, damit eine direkte Eingabe ermöglicht wird, doch dies muss ständig wiederholt werden.
Doch hierfür gibt es Abhilfe. Mit dem Befehl
gconftool-2 --set /apps/nautilus/preferences/always_use_location_entry --type bool 1
läßt sich die Leiste dauerhaft in den Eingabemodus umschalten.
PHP als Apache-Modul benutzt das CGI (Common Gateway Interface) um Anfragen an einen Webserver zu senden und das Resultat wieder an den Webbrowser zurückzusenden.
Dabei wird für jede Anfrage ein neuer Prozess erstellt, der nach der Verarbeitung des Scripts wieder beendet wird.
Hierdurch kann ein Overhead entstehen, da oftmals der Start des Scripts mehr Zeit in Anspruch nimmt, als dessen Verarbeitung. Weiterhin muss jedes Mal der PHP-Interpreter in den Speicher geladen werden.
Um diese Nachteile zu vermeiden ist die Verwendung von PHP5-fcgi ratsam, da unter FastCGI das auszuführende Programm (und der Interpreter) nur einmal geladen wird. Es steht dann für mehrere Requests zur Verfügung. Hierbei spielt es dann keine Rolle, ob der Request vom selben Client oder von unterschiedlichen Clients stammt.
Bei http://phpperformance.de findet sich eine sehr gute und detaillierte Erläuterung, welche Vor- und Nachteile mit der Benutzung von Fcgi in Kombination mit PHP5 einhergehen.
apt-get install libapache2-mod-fcgid php5-cgi apache2.2-common apache2-utils apache2-mpm-worker apache2-suexec
a2enmod fcgid
a2enmod suexec
adduser test
usermod -G test -a www-data
Der Parameter -a hängt die neue Gruppe an die bisherigen an und erhält damit die Gruppenzugehörigkeiten.
mkdir /var/www/test.tld
chown root:test /var/www/test.tld
chmod 750 /var/www/test.tld
mkdir /var/www/test.tld/conf
mkdir /var/www/test.tld/www
mkdir /var/www/test.tld/logs
mkdir /var/www/test.tld/tmp
mkdir /var/www/test.tld/php5
chown test:test /var/www/test.tld/*
chmod 750 /var/www/test.tld/*
cp /etc/php5/cgi/php.ini /var/www/test.tld/conf
vim /var/www/test.tld/conf/php
open_basedir = /var/www/test.tld/www/:/var/www/test.tld/tmp/
upload_tmp_dir = /var/www/test.tld/tmp
session.save_path = /var/www/test.tld/tmp
cat > /var/www/test.tld/php5/php-fcgi-starter << "EOF" #!/bin/sh PHPRC="/var/www/test.tld/conf/" export PHPRC exec /usr/bin/php5-cgi EOF
chown test:test /var/www/test.tld/php5/php-fcgi-starter
chmod 750 /var/www/test.tld/php5/php-fcgi-starter
chattr +i -V /var/www/test.tld/php5/php-fcgi-starter
cat > /etc/apache2/sites-available/test.tld << "EOF"
<VirtualHost *>
ServerAdmin chris@test.tld
ServerName test.tld
SuexecUserGroup test test
AddHandler fcgid-script .php
DocumentRoot "/var/www/test.tld/www"
DirectoryIndex index.htm index.html index.php
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory "/var/www/test.tld/www">
Options Indexes MultiViews FollowSymLinks +ExecCGI
FCGIWrapper /var/www/test.tld/php5/php-fcgi-starter .php
Order allow,deny
allow from all
</Directory>
ErrorLog /var/www/test.tld/logs/error.log
LogLevel warn
CustomLog /var/www/test.tld/logs/access.log combined
ServerSignature On
</VirtualHost>
EOF
a2ensite test.tld
/etc/init.d/apache2 restart
Nginx unterstützt im Gegensatz zum Apache-Server keine Chains in SSL-Zertifikaten. Das heißt, sie werden bei nginx nicht wie beim Apache-Server in der Konfiguration seperat ausgewiesen. Der Trick ist, die Chain-Datei an das eigentliche Zertifikat anzuhängen (cat chain.crt >> mysite.com.crt).
In der SSL-Dokumentation von nginx steht folgendes zu lesen:
This module enables HTTPS support.
It supports checking client certificates with two limitations:
* it’s not possible to assign a Certificate Revocation List for Nginx versions below 0.8.7.
* if you have a chain of certificates — by having intermediate certificates between the server certificate and the CA root certificate —
they’re not specified separately like you would do for Apache.
Instead you’ll need to concatenate all the certificates, starting with the server certificate,
and going deeper in the chain running through all the intermediate certificates.
This can be done with “cat chain.crt >> mysite.com.crt” on the command line.
Once this is done there’s no further use for all the intermediate certificates in what Nginx is concerned.
You’ll indicate in the Nginx configuration the file with all the (concatenated) certificates.
$ /etc/init.d/apache2 restart
Mit
$ sudo !!
wird der letzte Befehl als sudo erneut ausgeführt.
Der nächste Befehl ist das Äquivalent für vi, falls dieser nicht als sudo gestartet wurde.
:w !sudo tee %
$ mkdir /tmp/new $ cd !!:*
$ mkdir -p tmp/a/b/c
$ python -m SimpleHTTPServer alias webshare='python -c "import SimpleHTTPServer;SimpleHTTPServer.test()"'
$ cd -
$ mtr heise.de
$ apt-get install htop $ htop
alias ll='ls -lha' alias thor='ls -thor'
Zeige nur die Unterverzeichnisse des aktuellen Verzeichnisses an.
$ ls -d */
$ ps -auxf | sort -nr -k 4 | head -5
$ ps -auxf | sort -nr -k 3 | head -5
$ !suchterm:p $ history | grep suchterm
$ ssh-copy-id user@host
kopiert ssh-Schlüssel nach user@host um ssh-Logins ohne Passworteingabe zu ermöglichen.
Um die Schlüssel zu erzeugen, führen Sie
$ ssh-keygen
aus.
$ ffmpeg -f x11grab -s wxga -r 25 -i :0.0 -sameq /tmp/out.mpg
$ curl -u user:passwd -d status="Hi!" http://twitter.com/statuses/update.xml
$ curl -u username -o bookmarks.xml https://api.del.icio.us/v1/posts/all
$ > file.txt
$ shutdown -h 180
$ man -t ssh | ps2pdf - > ssh_manual.pdf $ acroread ssh_manual.pdf
$ cp /home/foo/langername.cpp{,-old}
PROMPT_COMMAND='history -n; history -a' HISTSIZE=100000 HISTFILESIZE=100000 HISTIGNORE="&:[ ]*:exit" shopt -s histappend
Ctrl-U - Linksseitige Einträge ausschneiden Ctrl-W - Wörter, die links vom cursor stehe ausschneiden Ctrl-Y - Einfügen des Pufferinhalts Ctrl-A - Zum Anfang der Zeile gehen Ctrl-E - Zum Ende der Zeile gehen
alias genpasswd='< /dev/urandom tr -dc A-Za-z0-9_ | head -c10 | more'
$ ps -C someprogram || { someprogram & }
$ mount -t tmpfs tmpfs /mnt -o size=1024m
Achtung! Wenn der Rechner neu gestartet ist, werden die Inhalte dieser Partition gelöscht.
find . -exec grep -l -e 'myregex' {} \; >> outfile.txt
find . -type d -exec chmod 755 {} \;
Quellen:
Wer einen gutes Tool sucht um unter Linux Prozesse zu betrachten und die Systemlast zu untersuchen ist mit top gut bedient. Doch es gibt noch ein weiteres sehr gutes Werkzeug, welches denselben Zweck erfüllt:
htop – zu finden bei http://htop.sourceforge.net/.
Die Installation gestaltet sich zumindest unter Debian- beziehungsweise Ubuntu-Systemen sehr einfach:
apt-get install htop
Mit htop wird die Software dann aufgerufen. htop bietet den Vorteil komplett mit der Maus bedienbar zu sein und die Darstellung wichtiger Systemeigenschaften wird meines Erachtens schöner dargestellt. Anbei ein Bild:
Die Auslastung der CPU und der Füllstand des Arbeitspeichers werden durch farbige Balken angezeigt. Dies ist vor allem bei Mehrprozessormaschinen interessant, da hier für jeden Prozessor ein eigener Infobalken dargestellt wird. Wie von top gewohnt, dürfen natürlich auch die Anzeige der Prozesse und die Einträge für den Systemload nicht fehlen. Prozesse können auch nach unterschiedlichen Kriterien geordnet angezeigt werden, Dazu dient das Menü ganz unten im Bild.
Haben Sie auch das Problem, sich jeden Tag auf viele unterschiedliche Server mit SSH einloggen zu müssen?
Ein Arbeitskollege hat mich auf einen kleinen Trick hingeweisen, der den Prozess etwas vereinfacht: Die Möglichkeit eine ssh-config zu erstellen.
Auf diese Weise wird die umständliche Schreibweise: ssh testserver@test.com -lUserName vermieden.
Als nächstes müssen Sie den Befehl “touch ~/.ssh/config” ausführen.
In diese Datei werden nun folgende Angaben mit aufgenommen (vim ~/.ssh/config):
Host t1
User chris
Port 22
HostName servername.test.com
Compression yes
Host test-alias2
User chris
Port 22
HostName servername.test2.com
Compression yes
usw…
Tada! Nur noch folgenden Befehl eingeben und schon gehts los: “ssh t1″’. Viel schneller gehts nicht, glaub ich …
Ich habe heute ein kleines Entwicklungssystem mit Trac und Subversion aufgesetzt und möchte das dokumentieren, da die Anpassung der Apache-Direktiven kein Spass ist. Der Schwerpunkt liegt wirklich auf der Apache Konfiguration, da es für die Installation von Apache2, Trac und Subversion sehr gute Tutorials gibt.
Der Zugriff auf Trac und SVN soll über https laufen und passwortgeschützt sein. Der Einhachheit wegen habe ich nur eine htpasswd erzeugt, welche sowohl von Trac, als auch von SVN benutzt werden und die auch dazu dient, die Webseiten zu schützen die später über Port 80 abrufbar sind (also, alles was in /var/www liegt).
Apache installieren (siehe http://www.howtoforge.com/perfect-server-ubuntu-9.04-ispconfig-2-p6) :
sudo apt-get install apache2 apache2-doc apache2-mpm-prefork apache2-utils apache2-suexec libexpat1 ssl-cert
Dann PHP5, Ruby, and Python als Apache-Module installieren:
sudo apt-get install libapache2-mod-php5 libapache2-mod-ruby libapache2-mod-python php5 php5-common php5-curl php5-dev php5-gd php5-idn php-pear php5-imagick php5-imap php5-mcrypt php5-memcache php5-mhash php5-ming php5-mysql php5-pspell php5-recode php5-snmp php5-sqlite php5-tidy php5-xmlrpc php5-xsl
Die /etc/apache2/mods-available/dir.conf anpassen:
vi /etc/apache2/mods-available/dir.conf
und diesen Abschnitt editieren:
#DirectoryIndex index.html index.cgi index.pl index.php index.xhtml index.htm DirectoryIndex index.html index.htm index.shtml index.cgi index.php index.php3 index.pl index.xhtmlTrac installieren: http://trac.edgewall.org/wiki/0.11/TracOnUbuntu
Selbst-signierte SSL Zertifikate erzeugen:
sudo openssl genrsa -out ./server.key 1024
sudo openssl req -new -key ./server.key -out ./server.csr
sudo openssl x509 -req -days 10000 -in ./server.csr -signkey ./server.key -out ./server.crt
Apache Direktiven anpassen (die AllowOverride AuthConfig ist wichtig, wenn man später auf .htaccess-Dateien in den Foldern verzichten möchte):
NameVirtualHost *:443
NameVirtualHost *:80
<VirtualHost *:80>
ServerName localhost
DocumentRoot /var/www/
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride AuthConfig
Order allow,deny
allow from all
AuthType Basic
AuthName “non-ssl websites”
AuthUserFile /etc/svn/.myprojects.passwd
Require valid-user
</Directory>
ErrorLog /var/log/apache2/error.log
LogLevel warn
CustomLog /var/log/apache2/access.log combined
ServerSignature Off
</VirtualHost>
#<VirtualHost *:80>
#ServerName potentieller zweiter VHost
#DocumentRoot /www/potentieller_zweiter_vhost
#</VirtualHost>
<VirtualHost *:443>
ServerAdmin webmaster@localhost
ServerName localhost
#DocumentRoot /var/www
ErrorLog /var/log/apache2/error.trac.log
CustomLog /var/log/apache2/access.trac.log combined
<Location /projects>
SetHandler mod_python
PythonInterpreter main_interpreter
PythonHandler trac.web.modpython_frontend
PythonOption TracEnvParentDir /var/lib/trac
PythonOption TracUriRoot /projects
PythonOption PYTHON_EGG_CACHE /tmp
</Location>
<Location /svn>
DAV svn
SVNPath /var/lib/svn/myprojects
AuthType Basic
AuthName “Subversion Repository”
AuthUserFile /etc/svn/.myprojects.passwd
Require valid-user
</Location>
# use the following for one authorization for all projects
# (names containing “-” are not detected):
<LocationMatch “/projects/[[:alnum:]]+/login”>
AuthType Basic
AuthName “trac”
AuthUserFile /etc/svn/.myprojects.passwd
Require valid-user
</LocationMatch>
# Enable/Disable SSL for this virtual host.
SSLEngine on
# A self-signed (snakeoil) certificate can be created by installing
# the ssl-cert package. See
# /usr/share/doc/apache2.2-common/README.Debian.gz for more info.
# If both key and certificate are stored in the same file, only the
# SSLCertificateFile directive is needed.
SSLCertificateFile /etc/apache2/ssl/server.crt
SSLCertificateKeyFile /etc/apache2/ssl/server.key
# Server Certificate Chain:
# Point SSLCertificateChainFile at a file containing the
# concatenation of PEM encoded CA certificates which form the
# certificate chain for the server certificate. Alternatively
# the referenced file can be the same as SSLCertificateFile
# when the CA certificates are directly appended to the server
# certificate for convinience.
#SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt
# Certificate Authority (CA):
# Set the CA certificate verification path where to find CA
# certificates for client authentication or alternatively one
# huge file containing all of them (file must be PEM encoded)
# Note: Inside SSLCACertificatePath you need hash symlinks
# to point to the certificate files. Use the provided
# Makefile to update the hash symlinks after changes.
#SSLCACertificatePath /etc/ssl/certs/
#SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt
# Certificate Revocation Lists (CRL):
# Set the CA revocation path where to find CA CRLs for client
# authentication or alternatively one huge file containing all
# of them (file must be PEM encoded)
# Note: Inside SSLCARevocationPath you need hash symlinks
# to point to the certificate files. Use the provided
# Makefile to update the hash symlinks after changes.
#SSLCARevocationPath /etc/apache2/ssl.crl/
#SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl
# Client Authentication (Type):
# Client certificate verification type and depth. Types are
# none, optional, require and optional_no_ca. Depth is a
# number which specifies how deeply to verify the certificate
# issuer chain before deciding the certificate is not valid.
#SSLVerifyClient require
#SSLVerifyDepth 10
# Access Control:
# With SSLRequire you can do per-directory access control based
# on arbitrary complex boolean expressions containing server
# variable checks and other lookup directives. The syntax is a
# mixture between C and Perl. See the mod_ssl documentation
# for more details.
#<Location />
#SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \
# and %{SSL_CLIENT_S_DN_O} eq “Snake Oil, Ltd.” \
# and %{SSL_CLIENT_S_DN_OU} in {“Staff”, “CA”, “Dev”} \
# and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \
# and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 ) \
# or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/
#</Location>
# SSL Engine Options:
# Set various options for the SSL engine.
# o FakeBasicAuth:
# Translate the client X.509 into a Basic Authorisation. This means that
# the standard Auth/DBMAuth methods can be used for access control. The
# user name is the `one line’ version of the client’s X.509 certificate.
# Note that no password is obtained from the user. Every entry in the user
# file needs this password: `xxj31ZMTZzkVA’.
# o ExportCertData:
# This exports two additional environment variables: SSL_CLIENT_CERT and
# SSL_SERVER_CERT. These contain the PEM-encoded certificates of the
# server (always existing) and the client (only existing when client
# authentication is used). This can be used to import the certificates
# into CGI scripts.
# o StdEnvVars:
# This exports the standard SSL/TLS related `SSL_*’ environment variables.
# Per default this exportation is switched off for performance reasons,
# because the extraction step is an expensive operation and is usually
# useless for serving static content. So one usually enables the
# exportation for CGI and SSI requests only.
# o StrictRequire:
# This denies access when “SSLRequireSSL” or “SSLRequire” applied even
# under a “Satisfy any” situation, i.e. when it applies access is denied
# and no other module can change it.
# o OptRenegotiate:
# This enables optimized SSL connection renegotiation handling when SSL
# directives are used in per-directory context.
#SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
<FilesMatch “\.(cgi|shtml|phtml|php)$”>
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
# SSL Protocol Adjustments:
# The safe and default but still SSL/TLS standard compliant shutdown
# approach is that mod_ssl sends the close notify alert but doesn’t wait for
# the close notify alert from client. When you need a different shutdown
# approach you can use one of the following variables:
# o ssl-unclean-shutdown:
# This forces an unclean shutdown when the connection is closed, i.e. no
# SSL close notify alert is send or allowed to received. This violates
# the SSL/TLS standard but is needed for some brain-dead browsers. Use
# this when you receive I/O errors because of the standard approach where
# mod_ssl sends the close notify alert.
# o ssl-accurate-shutdown:
# This forces an accurate shutdown when the connection is closed, i.e. a
# SSL close notify alert is send and mod_ssl waits for the close notify
# alert of the client. This is 100% SSL/TLS standard compliant, but in
# practice often causes hanging connections with brain-dead browsers. Use
# this only for browsers where you know that their SSL implementation
# works correctly.
# Notice: Most problems of broken clients are also related to the HTTP
# keep-alive facility, so you usually additionally want to disable
# keep-alive for those clients, too. Use variable “nokeepalive” for this.
# Similarly, one has to force some clients to use HTTP/1.0 to workaround
# their broken HTTP/1.1 implementation. Use variables “downgrade-1.0″ and
# “force-response-1.0″ for this.
BrowserMatch “.*MSIE.*” \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
ServerSignature Off
</VirtualHost>
Der ‘history’-Befehl unter Linux ist immer wieder nützlich um nachzusehen, was man früher in der Konsole eingegeben wurde. Standardmäßig ist die Historygröße in Ubuntu mit 500 Einträgen etwas knapp bemessen:
Doch das läßt sich leicht ändern:
vim /etc/profile
HISTSIZE=5000
. /etc/profile