So sieht’s hinter den Kulissen aus: http://stats.spiffytek.com/pub/map/
Das ganze wird mit Zabbix realisiert.
Die Map aktuallisiert sich derzeit alle fünf Minuten.
UnitedInternet/GMX/Web.de/1und1 „Warnt“ neuerdings beim Aufruf schön mit einem „Die Sicherheit ihres Rechners wird durch ein <Browsername hier> Add-On eingeschränkt“.
Folgt man der „Hilfe“ um dies zu beheben wird einem schön eingeflößt u.a. das Addon „Adblock“ zu entfernen. http://www.browsersicherheit.info/ NICE TRY!
Es mag zwar sein das es gefälschte Add-Ons diverser Populärer Erweiterungen gibt, aber die Warnung gibt es auch wenn es sich um ein original Add-On handelt.
Kurz um sieht es für mich nur nach einer Masche aus, um die Werbeeinnahmen zu erhöhen.
Update: Scheinbar wurde der „Fehler“ behoben. Zumindest wird bei AdBlock die Warnung nicht mehr ausgegeben.
Update 2 (01.03.2014): http://www.heise.de/newsticker/meldung/United-Internet-Adblocker-Warnungen-vorerst-beendet-2127834.html
In IspConfig 3.0.5.3 wurde ein nerviger Bug eingepflegt welcher es unmöglich macht das FTP-Heimverzeichniss zu editieren.
Verantwortlich dafür sind die Zeilen 94-95 der Datei ispconfig/interface/web/sites/ftp_user_edit.php
Update: Es gibt jetzt ein Patchtool um u.a. den hier genannten Fehler zu beheben. >>Link<<
Um den Fehler zu beheben muss
[code lang=“php“]$parent_domain = $app->db->queryOneRecord("select * FROM web_domain WHERE domain_id = ".$app->functions->intval(@$this->dataRecord["parent_domain_id"]) . " AND ".$app->tform->getAuthSQL(‚r‘));
if(!$parent_domain || $parent_domain[‚domain_id‘] != @$this->dataRecord[‚parent_domain_id‘]) $app->tform->errorMessage .= $app->tform->lng("no_domain_perm");[/code]
durch
[code lang=“php“]if(isset($this->dataRecord["parent_domain_id"])) {
$parent_domain = $app->db->queryOneRecord("select * FROM web_domain WHERE domain_id = ".$app->functions->intval(@$this->dataRecord["parent_domain_id"]) . " AND ".$app->tform->getAuthSQL(‚r‘));
if(!$parent_domain || $parent_domain[‚domain_id‘] != @$this->dataRecord[‚parent_domain_id‘]) $app->tform->errorMessage .= $app->tform->lng("no_domain_perm");
} else {
$tmp = $app->tform->getDataRecord($this->id);
$parent_domain = $app->db->queryOneRecord("select * FROM web_domain WHERE domain_id = ".$app->functions->intval($tmp["parent_domain_id"]) . " AND ".$app->tform->getAuthSQL(‚r‘));
if(!$parent_domain) $app->tform->errorMessage .= $app->tform->lng("no_domain_perm");
unset($tmp);
}[/code]
ersetzt werden.
Der fix befindet sich bereits im 3.0.5.4 Code-trunk. Diff gibt es hier.
Hier ein shöner Hack um eigene bzw. Kernelupdates auf den VM’s von DigitalOcean durchzuführen.
Folgend ein weg um XEN/KVM LVM Volume backups zu mounten um nachträglich Daten zu sichern oder Konfigurationen zu bereinigen.
1. Erstelle ein LVM Volume mit der gleichen größe des originals.
vg_myvol mit dem namen ihrer LVM Gruppe ersetzten.
[code]lvcreate -n restore –size 200G /dev/vg_myvol[/code]
2. Das backup in die neu erstellte „restore“ LVM einspielen.
In diesem Fall wäre das Backup in /dev/mapper/vg_myvol-restore einzuspielen.
3. Die Partitionen verfügbar machen.
[code]kpartx -av /dev/vg_myvol/restore[/code]
Dies erstellt unter /dev/mapper die jeweiligen Partitionen durchnummeriert im Stil vg_myvol-restore<nummer der Partition>
4. Die Partition mit welcher gearbeitet werden soll mounten.
Da sich auf den meisten XEN/KVM-Images nur zwei Partitionen befinden, wobei dabei die erste / und die zweite swap beinhaltet, mounten wir in diesem Beispiel gleich die erste Partition im „read-only“ Modus.
[code]mkdir -p /mnt/restore
mount -o ro /dev/mapper/vg_myvol-restore1 /mnt/restore[/code]
Sommit steht der Inhalt nun unter /mnt/restore zur Verfügung.
5. Nach beeindigung der Arbeit den Mount und LVM entfehrnen.
Optional: Neues Backup. Siehe Beispiel.
[code]umount /mnt/restore
kpartx -dv /dev/vg_myvol/restore
lvremove /dev/vg_myvol/restore[/code]