Aus aktuellem Anlass Gar nicht schön Nach längerem Suchen findet sich dazu hier eine Anleitung, wie das Problem behoben werden kann (incl. Verweis auf den Bug-Report bei Debian). Leider hat das bei mir wie angegeben überhaupt nicht funktioniert, verwendet hab ich statt dessen die folgende Variante: Package ins home kopieren und entpacken: Dann kann die Jetzt wieder packagen und anschließend installieren: Damit sollte die Installation dann problemlos durchlaufen.
brauch ich auf meinem Strato vServer ein jdk, der Server läuft unter Debian, sollte also kein großes Problem sein:
apt-get install java-package
fertig. Schön wärs, da kommt dann nämlich:
Setting up sun-java5-bin (1.5.0-10-3) ...
Could not create the Java virtual machine.
dpkg: error processing sun-java-5-bin (--configure):
subprocess post-installation script returned error exit status 1
cp /var/cache/apt/archives/sun-java5-bin_1.5.0-10-3_i386.deb ~
dpkg-deb -x ~/sun-java5-bin_1.5.0-10-3_i386.deb ~/sun-java
dpkg-deb -e ~/sun-java5-bin_1.5.0-10-3_i386.deb \
~/sun-java/DEBIAN
postinst in ~/sun-java/DEBIAN/postinst wie auf der verlinkten Seite angegeben abgeändert werden (also die Zeile:
$basedir/bin/java -client -Xshare:dump > /dev/null
per # auskommentiert werden).
dpkg-deb -b ~/sun-java/ ~/sun-java5-bin_1.5.0-10-3_i386.deb
dpkg -iR ./sun-java5-bin_1.5.0-10-3_i386.deb
Verfasst von nico am Samstag, 01. Januar 2008 | Keine Kommentare
Kategorie: howto
Problem war hier, das Subwiki einens allgemein zugänglichen Wikis nur für eine bestimmte Benutzergruppe zugänglich zu machen. Lösung siehe Chat-Protokoll 12:30] tobi: einstellungen in im DonauRies web werden übernommen…
[12:30] nico: ah, aber im intern nicht?
[12:30] tobi: genau
[12:30] nico: und in gruene?
[12:31] tobi: bin gerade dabei
[12:31] nico:
[12:35] tobi: ok, ich glaub ich habs:
[12:35] nico: ja?
[12:36] tobi: in allen super-wikis des entsprechenden sub-wikis muss mindestens ein Set ALLOWWEBVIEW = gesetzt sein
[12:36] tobi: sonst wird das in den subwikis nicht mehr evaluiert.
[12:36] tobi: sobald das überall drin is, funktionierts
[12:37] nico: it’s not a bug. it’s a feature
[12:37] tobi: genau
Verfasst von nico am Samstag, 05. Mai 2007 | Keine Kommentare
Eben hab ich das Programm KeePass auf meinen Treo 750 installiert. Mit dem Open-Source-Programm kann man Passwoerter und PINs sicher verwalten. Dazu bietet das Programm eine Menge an Features, wie z.B. eine ziemlich harte Verschlüsslung (AES, “Even if you would use all computers in the world to attack one database, decrypting it would take longer than the age of the universe.”), die Verwaltung verschiedener Passwort-Datenbanken oder die Installation auf einem USB-Key oder einen Passwort-Generator. Export und Import sind aus/in vielen verschiedenen Formaten möglich. KeePass laeuft neben Windows Mobile auch auf Windows XP, Linux, Mac OS und sogar auf meinem Treo 650/Palm OS, ist – wie gesagt – kostenlos und gibt’s unter http://keepass.info/
Verfasst von nico am Sonntag, 04. April 2007 | Keine Kommentare
Kategorie: howto,sicherheit
Sodala, nach langwierigen Tests koennen wir nun auch verschiedene Domains im mu-wordpress hosten. Folgende Schritte sind noetig: 1. DNS-Record anlegen 2. Domain fuer den Server konfigurieren – Falls der Blog auf www.domain.tld laeuft, domain.tld verwenden 3. Das htdocs Verzeichnis durch einen Symlink auf das htdocs-Verzeichnis unter blogs.netzbegruenung.de ersetzen 4. Blog in WordPress anlegen und die 4 Vorkommen der Domain entsprechend anpassen. Pfad muss auf / stehen, Permalink-Konfiguration loeschen. 5. Mit phpmyadmin einen neuen Eintrag in der Tabelle wp_site anlegen Path auf / 6. insert into wp_sitemeta (site_id, meta_key, meta_value) SELECT x, meta_key, meta_value FROM wp_sitemeta WHERE site_id = 1 ausfuehren und x durch die ID aus wp_site ersetzen 7. In der Tabelle wp_blogs site_id (aus vorherigem Schritt) und domain anpassen 8. In der Tabelle wp_xx_options die Domain entsprechend ändern. Das war’s auch schon!
Verfasst von nico am Friday, 04. April 2007 | Keine Kommentare
Nachdem Blogs von uns selbst eingerichtet werden sollen, hab ich die Einrichtung neuer Blogs deaktiviert. Dazu hab ich unter wp-content/mu-plugins die Datei signup-restrictions.php angelegt. <?php function nb_restrict_check() { } add_action(‘signup_header’, ‘nb_restrict_check’); ?> anschließend noch in der wp-signup.php den entsprechenden Radio-Button fuer “Blog erstellen” auskommentieren und checked=”checked” beim User-Radi-Button einfuegen. Fertig.
/*
Plugin Name: New Blog Restrictions
Plugin Author: Nico Ach
Author URI: http://www.netzbegruenung.de
Description: Restricts new blog creations on WordPress MU.
*/
switch ($_POST['signup_for']) {
case ‘blog’:
get_header();
echo ‘<div id=”content” class=”widecolumn”>’;
_e(‘Sorry, we are not accepting new blogs. Your new username has not been created. Please go back and select “Just a username, please.” instead. Thank you.’);
echo ‘</div>’;
get_footer();
die();
break;
}
Verfasst von nico am Friday, 04. April 2007 | Keine Kommentare
Hab mir gestern mal das Berechtigungs-/Zugriffsmanagement von TWiki im Detail angeschaut, mit sehr positivem Ergebnis: Das ganze is wesentlich einfacher, als es auf den ersten Blick schien. Deshalb hier mal in Kürze die wichtigsten Schritte zum Einrichten eines ‘eingeschränkten’ Wikis: More…1. Eine Gruppe für die entsprechenden BenutzerInnen anlegen Das macht Mensch auf der TWikiGroups seite im Main-Wiki. Dort per Eingabefeld und Button eine neue Gruppe anlegen (Namenseinschänkungen: CamelCase-Wort, muss auf Group enden, also z.B.GJSchwabenGroup). Das Bearbeiten von TWikiGroups hab ich auf die TWikiAdminGroup eingeschränkt. 2. Gruppenmitglieder in diese Gruppe aufnehmen Auf die Gruppenseite wechseln: Die Seite heißt wie die Gruppe, die Gruppenseiten befinden sich im Main-Wiki. Diese Seite bearbeiten und per Set GROUP = mitglied1, mitglied2, … Personen in die Gruppe aufnehmen. Wichtig: Set-Befehle funktionieren, wenn sie als Bullet-List angelegt sind, also: Drei Leerzeichen, Stern, Leerzeichen, dann der Set-Befehl. Außerdem sollte der Zugriff auf die Gruppenseite beschränkt werden, so dass sich nicht jedeR Neu-UserIn selbst in die Gruppe aufnehmen kann. Machbar ist dies über ein Set ALLOWTOPICCHANGE = {<user>|<gruppe>}, also z.B. Set ALLOWTOPICCHANGE=GJSchwabenGroup um nur Mitgliedern der GJSchwabenGroup die Bearbeitung der Seite (und damit die Aufnahme neuer Mitglieder) zu erlauben. 3. Zugriffsbeschränkungen auf Wiki-Ebene setzen Soll der Zugriff auf ein gesamtes Wiki (in TWiki-Dikition: Web) beschränkt werden, lassen sich dieser Beschränkungen über die WebPreferences Seite im jeweiligen Wiki setzen. Um die Einschränkungen zu setzen, muss mensch also ins entsprechende Wiki wechsel, und dort auf die WebPreferences-Seite. Unterstützt werden folgende Berechtigungen: * DENYWEBVIEW Alle Berechtigungen werden wie üblich per Set BERECHTIGUNG = {<user>,<user>,<gruppe>,…} gesetzt, ein explizites Deny schlägt ein Allow. Wie bei der Gruppenseite sollte auch hier die Edit-Berechtigung eingeschränkt werden, also mit Set ALLOWTOPICCHANGE = <WebAdminGruppe> das Setzen von Berechtigungen eingeschränkt werden. Funktioniert nach dem selben Schema, es existieren die selben Berechtigungen, in diesem Fall dann nicht ALLOWWEB… sonderen jeweils ALLOWTOPIC… Hier werden die Berechtigungen nicht auf einer eigenen Seite, sondern einfach im Artikel (am besten am Ende) gesetzt. Zugriffsbeschränkungen/-freigaben auf Seitenebene haben Vorrang gegenüber Zugriffsbeschränkungen auf Wiki-Ebene. Mehr Details? Gibts auf der TWikiAccessControl-Seite im TWiki-Web.
* ALLOWWEBVIEW
* DENYWEBCHANGE
* ALLOWWEBCHANGE
* DENYWEBRENAME
* ALLOWWEBRENAME
4. Zugriffsbeschränkungen auf Seitenebene setzen
Verfasst von nico am Donnerstag, 03. März 2007 | Keine Kommentare