This is a post from my original site, which was hosted by the former blog service of the University of Osnabrück. I have moved it to the new site for archiving. Pages linked in this article may no longer work today, and the blog comments under the article no longer exist. Opinions expressed in this article reflect the point of view of the time of publication and do not necessarily reflect my opinion today.
Einsatzbereich: 24/7-Linux-Server mit zu Beginn zwei oder drei virtuellen Maschinen.
Besondere Anforderungen: Einigermaßen geringer Stromverbrauch im Idle-Modus, SEHR leise.
Die 2,5"-Festplatte soll nur das Hostsystem beinhalten, sie wird also nach dem Start nicht mehr benötigt. Die Images der virtuellen Maschinen liegen auf dem Raid-Verbund.
Irgendwelche Anmerkungen dazu?
Nachtrag: Ja, der RAM ist etwas knapp kalkuliert, ich spekuliere auf weiter fallende Preise ;-) Und 2 GB hab ich hier auch noch zur Verfügung.
Nachtrag 2: Die Festplatten vielleicht lieber als "Samsung Spinpoint F2 EcoGreen HD103SI"? Haben beide sehr gute und sehr schlechte Bewertungen... Vorschläge?
Nachtrag 3: Netzteil wird wohl eher ein "be quiet! Pure Power L7 300W" oder ein "Seasonic S12II-330 Bronze".
This is a post from my original site, which was hosted by the former blog service of the University of Osnabrück. I have moved it to the new site for archiving. Pages linked in this article may no longer work today, and the blog comments under the article no longer exist. Opinions expressed in this article reflect the point of view of the time of publication and do not necessarily reflect my opinion today.
2014-02-26:
I've updated this HowTo for current versions of udev and kvm.
libvirt/kvm allows you to expose any usb device attached to your physical maschine to the guests. Just edit the domain's XML definition and add the following <hostdev> to the <devices> area:
<domaintype='kvm'>
...
<devices>
....
<!-- The XHCI driver includes support for USB 2 devices, which makes
it easier as with UHCI/EHCI to add an USB controller. Remove
existing USB controllers from definition. --><controllertype='usb'index='0'model='nec-xhci'/><hostdevmode='subsystem'type='usb'managed='yes'><sourcestartupPolicy='optional'><vendorid='0x03f0'/><productid='0x4217'/></source></hostdev></devices></domain>
Vendor id and product id can be determined with lsusb:
$ lsusb
...
Bus 002 Device 018: ID 03f0:4217 Hewlett-Packard EWS CM1015
...
Sadly this only works if the device is attached and enabled when the VM is started. The connection will be lost whenever the device is disabled or removed. But you can re-attach it at runtime. Just put the hostdev-definition into it's own file:
Previously, this example depended on sysFs{idVendor} and sysFs{idProduct} in order to match the correct USB device. These do not exist any longer, so I replaced them with environment variables containing the same information. To find out what attributes are available for matching, run udev monitor --property --udev while attaching and detaching the device.
This is a post from my original site, which was hosted by the former blog service of the University of Osnabrück. I have moved it to the new site for archiving. Pages linked in this article may no longer work today, and the blog comments under the article no longer exist. Opinions expressed in this article reflect the point of view of the time of publication and do not necessarily reflect my opinion today.
Soeben habe ich die neuen 2TB-Festplatten in den Media-PC eingebaut und mich dazu entschieden, dieses mal dem neuen Linux-Dateisystem btrfs eine Chance zu geben. Im Gegensatz zum klassischen ext beherscht dieses nämlich von Haus aus RAID-Funktionalitäten (Level 0, 1 und 10) sowie Snapshots. Das RAID im Level 1 schützt vor physikalischen Fehlern, die Snapshots - sofern man sie regelmäßig anlegt - vor logischen, wie einem versehentlichen 'rm -rf'.
Die Frage ist, wie stabil btrfs inzwischen geworden ist. Da es beinahe das Standardsystem unter Fedora 16 geworden wäre ist meine persönliche Einschätzung: Stabil genug für mich. Der Grund, warum FC16 doch noch ext4 verwendet, ist das fehlende bzw. nicht rechtzeitig fertig gewordene fsck. Mit den git-Quellen jedoch kein Problem, dort findet sich inzwischen ein btrfsck. Sowieso würde ich für den Einsatz einen aktuellen Kernel (3.x) und die aktuellen Tools aus dem Git-Repository verwenden, siehe https://btrfs.wiki.kernel.org/.
Zuerst müssen die Partitionen im RAID-1-Modus formatiert werden:
Im Gegensatz zu einem klassischen mkfs gibt man hier also zwei (bzw. mehr) Devices an. Mit den Parametern -d (--data) und -m (--metadata) wird der jeweilige Speichermodus festgelegt. Standardmäßig spiegelt btrfs bei mehr als einer Partition die Metadaten (raid1) und teilt die Daten auf beide Devices auf (raid0).
Damit btrfs alle zusammengehörigen Partitionen automatisch finden kann, erhalten sie die selbe UUID und unterschiedliche Sub-UUIDs:
Dementsprechend reicht es beim Mounten auch aus, entweder eines der beiden Devices oder die UUID anzugeben. Die folgenden drei Befehle sind also identisch zueinander:
$ mount /dev/sdd1 /mnt
$ mount /dev/sde1 /mnt
$ mountUUID=243efbc4-5f72-4352-9160-d693b3ed41b5 /mnt
Der Befehl btrfs filesystem show zeigt alle erkannten Dateisysteme an:
$ sudo btrfs filesystem show
Label: 'mediafiles' uuid: 243efbc4-5f72-4352-9160-d693b3ed41b5
Total devices 2 FS bytes used 809.82GB
devid 1 size 1.82TB used 817.03GB path /dev/sdd1
devid 2 size 1.82TB used 817.01GB path /dev/sde1
Btrfs v0.19-102-g2482539
Es gibt jedoch eine kleine Stolperfalle. Soll das RAID-1-btrfs beim Booten automatisch eingehängt werden, so *müssen* alle Devices in der /etc/fstab eingetragen werden. Ansonsten meckert das System, da es nicht alle dazugehörigen Devices selbst finden kann, selbst wenn die UUID verwendet wird:
Gefährlich ist dies vor allem bei Headless-Systemen, da im laufenden Betrieb die automatische Erkennung der Devices durchaus funktioniert und ein Eintrag ohne die device=-Optionen daher beim Testen durchaus funktionieren würde.
Nicht ganz einfach ist übrigens die Größe bzw. der freie Speicher des RAID-1-Dateisystems zu ermitteln:
df zählt hier also einfach den gesamten und belegten Speicher aller Einzelpartitionen zusammen. Der Grund hierfür liegt, soweit ich das im Wiki verstanden habe, in einem Berechtigungsproblem: Um das Dateisystem als RAID-1 zu erkennen und die Größe damit korrekt anzugeben müsste df direkt darauf zugreifen, was ihm aber zumindest als normaler User nicht erlaubt ist. btrfs bringt daher sein eigenes df mit:
Das Tool btrfs wird auch verwendet, um weitere Devices zum Raid hinzuzufügen, zu entfernen, Snapshots anzulegen oder das FS zu defragmentieren. Hiermit habe ich bisher aber noch nicht experimentiert, ggf. wird's einen Nachtrag geben. Erstmal werde ich nun das Verhalten im MythTV-Betrieb beobachten und vor allem auf die - subjektive - Performance im Vergleich zu ext4 achten.
This is a post from my original site, which was hosted by the former blog service of the University of Osnabrück. I have moved it to the new site for archiving. Pages linked in this article may no longer work today, and the blog comments under the article no longer exist. Opinions expressed in this article reflect the point of view of the time of publication and do not necessarily reflect my opinion today.
Apache's include directive does not accept wildcards, so something like this won't be allowed:
Include /srv/www/vhosts/*/conf/vhost.conf
You can use mod_perl to realize this. Additionally, the following example does a simple permission check to ensure that the included file has not been modified by an ordinary user:
<perl>use File::stat;foreach$file(glob '/srv/www/vhosts/*/conf/vhost.conf'){my$stat= stat($file);if($stat->uid !=0||$stat->gid !=0){
warn "$file is not owned by root:root, skipping!\n";next;}if($stat->mode &0002){
warn "$file is world-writable, skipping!\n";next;}
push @Include,$file;}</perl>
This is a post from my original site, which was hosted by the former blog service of the University of Osnabrück. I have moved it to the new site for archiving. Pages linked in this article may no longer work today, and the blog comments under the article no longer exist. Opinions expressed in this article reflect the point of view of the time of publication and do not necessarily reflect my opinion today.
This is a re-post of my mail to the suphp mailing list. Although the behaviour described here is a serious design issue, I've never got any feedback.
The attached patch is some kind of "proof of concept" to solve a security related problem I have with suPHP.
Problem: Run script with file/directory owner threatens the user's files.
suPHP is intended to run a PHP script using a specific process owner. When configured in "owner" or "paranoid" mode this always will be the owner of the file, but in any case it will be executed having the same owner as the parent directory (if it isn't owned by root).
This can be (and I think in most cases is) used in multihosting environments to prohibit the users from reading other user's files on an operating system level.
But there is a big security problem with this solution. Not only an exploitable PHP script can modify itself, but it is also possible for an attacker to compromise the user's configuration files. E.g. a bad guy could place a key logger in the user's .profile file. Or even simpler, fake a failed login to retrieve the user's password.
A solution can be to execute the PHP process only with the user's group and a restricted "nobody" user. Sadly, suPHP wouldn't allow the script to be executed if it and it's parent directory are not owned by the nobody user. Not a very satisfying situation if you need the system administator's help to modify your site.
My suggestion is to distinct between the user/group the script is executed with and the user/group the script have to be owned by. The attached patch (quick&dirty, only for apache2) add's an optional third parameter "processUser" to suPHP_UserGroup and a new environment variable SUPHP_PROCESS_USER, but maybe a new configuration directive named "suPHP_ScriptOwner" is preferable. Ownership checks are done using targetUser, permission change is done using processUser. If empty, processUser = targetUser.
This way you even can ensure that a php file created by suPHP (e.g. because of a file upload with .php extension into a public directory or an exploitable call to file_put_contents()) would never be executed - because it is owned by processOwner where it should be owned by targetUser!
Create a branch production which contains all changes that should went onto the production server:
$ hg branch production &&hg commit -m"Added new branch 'production'"
Clone repo to remote:
$ hg clone . ssh://user@host//path/to/repository
On the server, switch to production branch:
$ hg update production
Now add the following hook into the .hg/hgrc:
[hooks]# If current branch is out of date, update and refreshchangegroup=(LANG=C hg summary | grep -q 'update: (current)' || (hg update && mvn clean compile install && systemctl )) >&2
This example uses Maven to rebuild the src into the target directory if any update in the production branch appears.