-Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl

Am einfachsten geht's aber mittlerweile mit Maven, siehe http://wiki.apache.org/myfaces/MyFaces_Archetypes_for_Maven.

Eigentlich sind solche Archteypen ja etwas für MDA-"FUDders", denn der Unterschied hinsichtlich der Vorgehensweise zur JSF-Cartridge von AndroMDA ist gar nicht so groß. 

Zur Dokumentation: 

<?xml version="1.0"?><web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"> 

    <context-param>        <description>            State saving method: "client" or "server" (= default)            See JSF Specification 2.5.2        </description>            <param-name>javax.faces.STATE_SAVING_METHOD</param-name>        <param-value>server</param-value>    </context-param>

    <context-param>        <description>            This parameter tells MyFaces if javascript code should be allowed in the            rendered HTML output.            If javascript is allowed, command_link anchors will have javascript code            that submits the corresponding form.            If javascript is not allowed, the state saving info and nested parameters            will be added as url parameters.            Default: "true"        </description>            <param-name>org.apache.myfaces.ALLOW_JAVASCRIPT</param-name>        <param-value>true</param-value>    </context-param>

    <context-param>        <description>            This parameter tells MyFaces if javascript code should be allowed in the            rendered HTML output.            If javascript is allowed, command_link anchors will have javascript code            that submits the corresponding form.            If javascript is not allowed, the state saving info and nested parameters            will be added as url parameters.            Default: "false"

            Setting this param to true should be combined with STATE_SAVING_METHOD "server" for            best results.

            This is an EXPERIMENTAL feature. You also have to enable the detector filter/filter mapping below to get            JavaScript detection working.        </description>        <param-name>org.apache.myfaces.DETECT_JAVASCRIPT</param-name>        <param-value>false</param-value>    </context-param>

    <context-param>        <description>            If true, rendered HTML code will be formatted, so that it is "human readable".            i.e. additional line separators and whitespace will be written, that do not            influence the HTML code.            Default: "true"        </description>        <param-name>org.apache.myfaces.PRETTY_HTML</param-name>        <param-value>true</param-value>    </context-param>

    <context-param>        <description>            If true, a javascript function will be rendered that is able to restore the            former vertical scroll on every request. Convenient feature if you have pages            with long lists and you do not want the browser page to always jump to the top            if you trigger a link or button action that stays on the same page.            Default: "false"        </description>            <param-name>org.apache.myfaces.AUTO_SCROLL</param-name>        <param-value>true</param-value>    </context-param>

    <!-- Extensions Filter -->    <filter>        <filter-name>MyFacesExtensionsFilter</filter-name>        <filter-class>org.apache.myfaces.webapp.filter.ExtensionsFilter</filter-class>        <init-param>            <description>Set the size limit for uploaded files.                Format: 10 - 10 bytes                        10k - 10 KB                        10m - 10 MB                        1g - 1 GB            </description>        			<param-name>maxFileSize</param-name>			<param-value>20m</param-value>        </init-param> </filter> <filter-mapping>  <filter-name>MyFacesExtensionsFilter</filter-name>  <!-- servlet-name must match the name of your javax.faces.webapp.FacesServlet entry -->  <servlet-name>Faces Servlet</servlet-name> </filter-mapping> <!-- extension mapping for serving page-independent resources (javascript, stylesheets, images, etc.)  --> <filter-mapping>  <filter-name>MyFacesExtensionsFilter</filter-name>  <url-pattern>/faces/myFacesExtensionResource/*</url-pattern> </filter-mapping> <filter-mapping>  <filter-name>MyFacesExtensionsFilter</filter-name>  <url-pattern>*.jsp</url-pattern> </filter-mapping>

 <!-- Listener, that does all the startup work (configuration, init). --> <listener>  <listener-class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class> </listener> <!-- Faces Servlet --> <servlet>  <servlet-name>Faces Servlet</servlet-name>  <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>  <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping>  <servlet-name>Faces Servlet</servlet-name>  <url-pattern>*.jsf</url-pattern> </servlet-mapping> <servlet-mapping>  <servlet-name>Faces Servlet</servlet-name>  <url-pattern>/faces/*</url-pattern> </servlet-mapping> <login-config>  <auth-method>BASIC</auth-method> </login-config></web-app>

Schließlich half, t3lib/class.t3lib_div.php zu bearbeiten:

curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 0); // Changed from 0 to 1 by KG curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);

 So schleicht sich die Homepage für die Gemeinde voran, immerhin ist die neue cal-Extension exzellent.

Benutzer von KDE haben's da aber komfortabler: Sie brauchen nur fish://[Benutzer]@[Hostname/-IP-Adresse[:Portnummer]] einzugeben und ihr PW zu speichern, schon können sie auf den entfernten Server zugreifen.

Sehr angenehme Lösung, vor allem mit der KWallet-Integration. Vorteilhaft ist auch, dass man – wenn auch mit Performancenachteilen bei Fremdhostern – in einer Zwei-Panel-Ansicht ("Midnight-Commander"-Modus) sogar von einem Remoteserver zum anderen Dateioperationen ausführen kann.

Falls das nicht funktionieren sollte (z.B. wg. Firewalls auf der Serverseite, die nur für SCP/SFTP freigegeben sind – funkioniert manchmal nicht ohne ersichtlichen Grund [Pakete noch nicht angeschaut]): Einfach mal sftp://(…) ausprobieren!  

Der Hinweis auf http://kerneltrap.org/node/3374 brachte die Lösung:
Als Startparameter des Bootloaders “psmouse.proto=imps” eintragen (und xorg.conf entsprechend anpassen, falls nicht geschehen, also “Option “Protocol” “IMPS/2″.

Neustarten, funktioniert zuverlässig.

User wurde mit einem Namen aus einem Wort erstellt, z.B. “jamessmith”.

Erst einmal geprüft, ob cyrus-imap läuft (musste unter SuSE 10.1 übrigens mit speziellen rpmseed-Packages nachinstalliert werden). Nach kleineren Berechtigungsproblemen war soweit alles OK.

su - cyrus -c '/usr/lib/cyrus/bin/reconstruct -rfx "user.jamessmith"'

Das wars. Wirklich sehr komfortabel

1. Als root einloggen.

2. openssl.conf anpassen, falls noch nicht geschehen (siehe openssl.cnf – "myWonderfulHostname" mit entsprechendem Servernamen ersetzen…). Am wichtigsten ist das commonName-Attribut!

3. Verzeichnis anlegen

cd ~ && mkdir myWonderfulHostnameCA && cd myWonderfulHostnameCA

4. Unterverzeichnisse anlegen

mkdir certs newcerts crl private && touch index.txt && echo "01" > serial

5. Jetzt wird die CA erzeugt. Zur Sicherheit commonName manuell eingeben. Passphrase gut sichern!!!

openssl req -new -x509 -keyout private/myWonderfulHostnameCA_prv_key.pem -out myWonderfulHostnameCA_cert.pem -days 3650

6. Schlüsselpaar für den Server erzeugen.

openssl req -new -keyout certs/myWonderfulHostname_prv_key.pem -out certs/myWonderfulHostname_req.pem -days 3650

7. Unverschlüsselten Key erzeugen. – Wenn dieser benutzt wird, sollte man sich um die Rechte so kümmern, dass nur die Prozesse darauf zugreifen können, die ihn benötigen! Das ginge ggf. mit ACLs.

openssl rsa < certs/myWonderfulHostname_prv_key.pem > myWonderfulHostname_prv_key-unverschluesselt.pem

8.

9. Öffentlichen Schlüssel mit privatem der CA unterschreiben:

openssl ca -policy policy_anything -notext -out certs/myWonderfulHostname_cert.pem -infiles certs/myWonderfulHostname_req.pem

10. Jetzt gehts daran, Apache unsere Files bekannt zu machen. Erst einmal /etc/httpd/conf/ssl. sichern! Apache benötigt:

• • SSLCertificateFile (default: server.crt) => Das entspricht dem von uns generierten /root/myWonderfulHostnameCA/certs/myWonderfulHostname_cert.pem.
• • SSLCertificateKeyFile (default: server.key) => Wenn wir die unverschlüsselte Version verwenden möchten (keine PW-Abfrage beim Apache reboot) nehmen wir: /root/myWonderfulHostnameCA/myWonderfulHostname_prv_key-unverschluesselt.pem , ansonsten benutzt der Hardcore-Admin bestimmt viel lieber /root/myWonderfulHostnameCA/certs/myWonderfulHostname_prv_key.pem

… Also:

mv /etc/httpd/conf/ssl.crt/server.crt /etc/httpd/conf/ssl.crt/server.crt.bak && cp /root/myWonderfulHostnameCA/certs/myWonderfulHostname_cert.pem /etc/httpd/conf/ssl.crt/server.crt

und

mv /etc/httpd/conf/ssl.key/server.key /etc/httpd/conf/ssl.key/server.key.bak && cp /root/myWonderfulHostnameCA/myWonderfulHostname_prv_key-unverschluesselt.pem /etc/httpd/conf/ssl.key/server.key

11.

12. Apache neustarten.

apachectl stop && apachectl start