When trying to install Windows security rollup update on computer with dual boot, Windows Update always fails.

Symptom

During shutdown, Windows starts preparing the update and during the next boot, it continues until around 80-100%. Then it fails, rolls back the upgrade and reboots again. After that, the update is still listed for installation and shows as failed attempt in the update log with error code 80004005.

Solution

1. Get Windows to boot using its native boot loader

Windows will then boot the active partition from MBR, temporarily remove the boot loader!. So make sure that partition where Windows is installed is the active partition (e.g. using Disk Management)!

Start Ubuntu (either installed one or from a USB Stick) and run following commands:

sudo apt-get install mbr
sudo install-mbr -i n -p D -t 0 /dev/sdX

(replace sdX with the disk where Windows is installed!)

Attention: This makes your linux installation unbootable if you run mbr command on the disk you normally boot Linux from, so ensure:
- you have a current backup of your value data
- have a USB stick at hand with Ubuntu ISO Image

If you have installed Windows on an other (second) harddisk, also go to BIOS Setup and change boot order so the disk containing Windows is in first order (before the one containing Linux).

2. Install Security Rollup Update

On subsequent reboots, your computer will now boot directly into Windows (without showing GRUB menu anymore).

Start Security Rollup Update again:
* Go to Windows Update (Control Panel -> Sytem and Security -> Windows Update)
* Choose "Check for updates"
* Make sure Security Rollup is selected
* Choose "Install Updates"

This time, after 2-3 reboots, update should succeed.

3. Make Linux bootable again

a) When changed boot order to start Windows directly from another disk, go to BIOS Setup again and switch order back, so the harddisk with GRUB installed will be ordered before the HD containing Windows installation.

b) When installed "original" MBR to the disk where GRUB was installed, you have to repair the Linux Bootloader:
* boot using a USB Stick containing e.g. Ubuntu Linux ISO image
* mount your root and boot Linux partitions, e.g.

mkdir -p /mnt/root && mount /dev/sda6 /mnt/root && mount /dev/sda5 /mnt/root/boot

(replace with device where your linux partitions resides, if in doubt, first run fdisk -l /dev/sda)

* chroot your Linux installation:

chroot /mnt/root /bin/bash

* install grub again to Master Boot Record, e.g.

grub-install /dev/sda

(grub configuration should be available on /boot)

* Exit chroot environment

exit

* Unmount Linux partitions:

umount /mnt/root/boot /mnt/root

* reboot your system

You now should see GRUB boot menu again, where you can boot either Linux or Windows...

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!

Sometimes, you need to test SMTP auth (for sending e-mails) is working properly and you don't want (or can't) test with an ordinary email client.

One can test using a telnet session. But first, you must encode username and password using this command snipplet:

echo -en "testlogin" | openssl enc -base64
dGVzdGxvZ2lu
echo -en "testpass" | openssl enc -base64
dGVzdHBhc3M=

Then:

telnet <your_server_address> 25 (or 587)

Now you do the same as an e-mail client:

HELO mybox.mydomain.tld
250 host.domain.tld
AUTH LOGIN
334 VXNlcm5hbWU6
dGVzdGxvZ2lu
334 UGFzc3dvcmQ6
dGVzdHBhc3M=
235 2.7.0 Authentication successful
quit
221 2.0.0 Bye

If something with "Authentication successful" appears, login was able to authenticate against the mail server for sending e-mail.

REMARK: There are some other sites with examples in perl that don't work with full e-mail address usernames (user@domain.tld) because of lack of escaping the "@" sign that designates a perl array.

Add the following to your SSL configuration section:

   # Disable SSLv2 & SSLv3 against POODLE issue (CVE-2014-3566)
    SSLProtocol All -SSLv2 -SSLv3

Note to insert this to all VirtualHost sections where SSL is enabled!

Check your config:

apachectl configtest

Then restart apache server:

sudo service apache2 restart

To check if SSLv3 is turned off:

openssl s_client -connect server.domain.tld:443 -ssl3

Then you shold see a message like this:

error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1260:SSL alert number 40

To disable SSLv3 within other services:
see this post

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.