Damit man über einen Reverse-Proxy auf einen Web-Server zugreifen kann, welcher seinerseits wieder mit HTTP Basic Authentifizierung geschützt ist (und im Backend andere Login-Informationen als für die Anmeldung am Reverse Proxy erforderlich sind), muss die HTTP-Authentifizierung für den Backend-Server im Proxy-Abschnitt mitgegeben werden.

Dazu muss zuerst Benutzername und Passwort in eine Base64-Zeichenkette encodiert werden:

echo -n "User:Pass" | base64
VXNlcjpQYXNz

(auch wenn kein Benutzername benutzt wird, muss das Doppelpunkt im zu encodierenden String enthalten sein!)

Danach in der Konfiguration des als Reverse-Proxy verwendeten Frontend-Servers folgendes z.B. in einen Location-Abschnitt hinzufügen.

Apache:

RequestHeader set Authorization "Basic VXNlcjpQYXNz"

Nginx:

proxy_set_header Authorization "Basic VXNlcjpQYXNz";

Technischer Hintergrund:

Sofern dieselben Anmelde-Informationen im Backend verwendet werden wie im Frontend (Reverse-Proxy), sollte dieses bei der nachfolgenden HTTP-Auth Anfrage transparent vom Client Web-Browser weitergereicht werden, und obiger Parameter ist nicht notwendig.

Wird hingegen versucht, sich mit unterschiedlichen HTTP-Auth Passwörter anzumelden (zuerst dasjenige für den Reverse-Proxy, dann dasjenige, welches der Backend-Webserver verlangt), ist darauf sofort die Anmeldung am Proxy nicht mehr gültig -> Ein Zugriff würde so also nie funktionieren!

Issue the following command:

openssl s_client -CApath /etc/ssl/certs/ -connect <host.domian.tld>:993

For testing on a mail server supporting both non-encrypted and encrypted (TLS) connections using STARTTLS method:

openssl s_client -CApath /etc/ssl/certs/ -starttls smtp -connect <host.domian.tld>:25

There should be stated quite at end of command output:

    Verify return code: 0 (ok)

before an eventual greeting message of the server.

A bit above, you can check the certificate chain completeness:

Certificate chain
 0 s:/description=3UwjnK9kRZ2wUo8e/C=CH/CN=domain1.ownspace.ch/emailAddress=hostmaster@ownspace.ch
   i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
 1 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
   i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
---

The last i(ssuer) is the root cert that most client will trust.

This small shell script removes all messages originating from a certain sender address out of the postfix mail queue.

#! /bin/bash
if [ "$1" == "" ]; then
  echo "please give e-mail address"
  exit 1
else
  emailaddr=$1
fi
for id in `mailq | egrep "[0-9A-F]{10} " | grep "$emailaddr" | cut -d " " -f 1`
do
  echo $id
  postsuper -d $id
done

A real PITA is to use the Console redirection of the integrated / optional iKVM of ASUS servers.

Access to the web-GUI (directly or even forwarded like 127.0.0.1:8080 tunneled through ssh to the iKVM's real ip behind a jump host) is quite straight-forward and easy to use.

But the console redirection slightly doesn't work even directly (server has the IP address you type in your web-browser) and with properly installed Java Web Start, at least with version 2.13 of the iKVM firmware.

So this workaround may help:
1. Log in to the Web-GUI

2. Start the Java console under Remote Control

3. Download the .jnlp file instead of opening Java Web Start directly
4. Edit the file as following:

<argument>127.0.0.1:8080</argument>
to
<argument>127.0.0.1</argument>

(for example if you have forwaded or mapped the real port 80 to
8080, this has to be only the IP address WITHOUT the port)

<argument>0</argument>
to
<argument>7578</argument>

(this has to be the port where the (local) Java Client will connect to the remote server's console and not '0', may also be another port when you do a port mapping or forwarding)

5. Now open the jviewer.jnlp file with Java Web Start.

The console should now show up...

(for all ports involved see the related link to the ASUS support site)

In some situations, there even the download of the JAVA files stucks with 0%. Perhaps then you experience some troubles with SSL because some INTEL ikvm will try to use HTTPS (even if you connect to the iKVM GUI with only HTTP). So use again a manually edited .jnlp file:

1. Download the jnlp file instead of opening directly

2. Change the line with the keyword codebase by replacing the "https://" with just "http://"

<jnlp spec="1.0+" codebase="http://<your_ikvm_ip>/Java" >

3. Open the jviewer.jnlp file with Java Web Start

For having an intuitive GUI synchronisation client, you may use grsync using a gvfs path on Linux or a Drive Letter on Windows where the WebDAV Storage is preliminary mounted. Or go for the commercial sync tool GoodSync which has WebDAV protocol built-in.

But now, when you try to synchronise with the WebDAV storage (e.g. to OwnSpace Web Storge or to Dropbox), you probably get many "file not found" errors and you end up with no files on the WebDAV storage.

To get that to work, you must use the rsync option "--inplace". Search for rsync options or an option meaning "directly write to files instead of temporary files".