Fiber7 mit einer FortiGate Next Generation Firewall

Author: | Categories: Fortinet No comments

Fiber7

Mit Fiber7 bietet der Winterthurer ISP Init7 seit 2014 einen FTTH basierendes Produkt mit einer festen symmetrischen Bandbreite von 1 Gbit/s für jährlich 777.- Fr. an. Fiber7 kommt immer mit native IPv6, welches per DHCPv6 verteilt wird. Optional kann man neben fixen IPv4 und IPv6 Adressen auch SLAs für Business Anschlüsse an.

Die Init7 setzt auf ihren Fiber7 Anschlüssen ausschliesslich auf Ethernet (untagged) mit DHCPv4 und DHCPv6 und bietet eine freie Router Wahl an. Somit kann auf den Fiber7 Anschlüssen problemlos eine Enterprise Firewall von Fortinet eingesetzt werden.

 

Hardware

Um die Bandbreite von 1 GBit/s bewerkstelligen zu können, benötigt man bei den kleineren FortiGate Modellen mindestens ein SOC3 basierendes Gerät. Das kleinste Gerät mit einem SOC3 ist die lüfterlose FortiGate 60E, welche mit einem maximalen Durchsatz von 3 GBit/s ausreichend Bandbreite für einen Fiber7 Anschluss bietet.

Da die FortiGate 60E ausschliesslich über Gigabit Kupfer Ports verfügt, ist ein zusätzlicher Media Converter notwendig. Ein entsprechender Media Converter, wie der TP-Link MC220L kann direkt bei der Init7 mit der entsprechender Optik bezogen werden.

Das nächst grössere Modell, die FortiGate 80E, ist ebenfalls lüfterlos und verfügt über 2 SFP Slots. Die Optik, die man zusammen mit dem Patchkabel von der Init7 beziehen kann, funktioniert tadellos in der FortiGate 80E.

 

Konfiguration

Interfaces

In einem ersten Schritt konfigurieren wir das WAN Interface. Die Init7  benutzt auf ihren Fiber7 standard DHCPv4 und DHCPv6-PD.

config system interface
   edit "wan1"
    set vdom "root"
    set mode dhcp
    set allowaccess ping
    set type physical
    set alias "Fiber7"
    set role wan
    config ipv6
       set ip6-mode dhcp
       set ip6-allowaccess ping
       set dhcp6-prefix-delegation enable
   end
   next
end

 

Als zweiter Schritt muss das LAN Interface konfiguriert werden:

config system interface
   edit "internal1"
   set vdom "root"
   set ip 192.168.0.1 255.255.255.0
   set allowaccess ping https ssh
   set alias "Clients"
   set device-identification enable
   set fortiheartbeat enable
   set role lan
   config ipv6
      set ip6-allowaccess ping https ssh
      set ip6-send-adv enable
      set ip6-subnet ::1/64
      config ip6-delegated-prefix-list
         edit 0
         set upstream-interface "wan1"
         set autonomous-flag enable
         set onlink-flag enable
         set subnet ::/64
         next
      end
   end
   next
end
  • set ip6-mode delegated – Definiert, dass die IP Adresse für dieses Interface über eine IPv6  Prefix Delegation definiert wird
  • set ip6-send-adv enable – Erlaubt das aussenden von Router Advertisements auf diesem Interface
  • set ip6-upstream-interface "wan1" – Definiert von welchem Interface die Prefix Delegation kommt
  • set ip6-subnet ::1/64 – Das Interface soll die erste IP Adresse im /64 Subnet benutzen.

 

Zusätzlich muss mit ip6-delegated-prefix-list eine delegierte prefix liste definiert werden, um die über DHCPv6-PD erhaltenen Adressen zu verteilen. Man kann mehrere definieren, in diesem Beispiel definiere ich jedoch nur eines:

  • set autonomous-flag enable – Erlaubt den Clients ihre eigenen globalen IPv6 Adressen zu konstruieren.
  • set onlink-flag enable – Benutze im Prefix des Router Advertisements “On-Link” Adressen (Details)
  • set subnet ::/64 – Benutze das erste /64 vom /48, welches wir per DHCPv6 erhalten haben.

 

Zum Abschluss benötigen wir noch zwei Firewall Policies, jeweils eine für IPv4 und eine für IPv6:

config firewall policy
   edit 0
      set name "Internet Access IPv4"
      set srcintf "internal1"
      set dstintf "wan1"
      set srcaddr "all"
      set dstaddr "all"
      set action accept
      set schedule "always"
      set nat enable
   next
end

 

config firewall policy6
   edit 0
      set name "Internet Access IPv6"
      set srcintf "internal1"
      set dstintf "wan1"
      set srcaddr "all"
      set dstaddr "all"
      set action accept
      set schedule "always"
   next
end

 

Bezug

Die FortiGate Firewalls können von einem autorisierten Reseller bezogen.

Setting up a private OmniFocus sync server with Nginx

Author: | Categories: Allgemein No comments

OmniFocus is is an outstanding task manager for MacOS and iOS from OmniGroup. It works with the Getting Things Done® methodology and helps you to manage your task list. Keeping your tasks outside of your head, helps you to concentrate on your work and not on your tasks.

To good thing with OmniFocus is, that you can sync your data with your iPhone or iPad. You can use either OmniGroups sync server or you can use your own WebDAV server. OmniFocus supports also push updates through APNS, even if you use your own sync server, which is really nice.

Starting with OmniFocus for Mac 2.9 and OmniFocus for iOS 2.19, the Nginx web server is also supported. It is now finally possible to use Nginx as a WebDAV server for OmniFocus without implementing any weird hacks .

Before you start with the configuration, please make sure your Nginx web server is built with the HTTP_DAV and HTTP_DAV_EXT modules. Verify with the command  “nginx -V” if Nginx is built with these modules.

If the modules are present in your Nginx setup, we can start with the configuration…

As a first step, we have to create a htpasswd file for authentication. As Nginx does not provide a utility for that, we have to use this magic command to create a htpasswd file:

echo -e "your-username:`perl -le 'print crypt("your-password","salt")'`" > htpasswd

Copy the htpasswd to right place and make sure, that not everybody can access the file.

The next step is the configuring Nginx. Start your favorite editor and place the settings bellow within the server context in your nginx.conf file

location /webdav {
        root             /var/webdav/$remote_user;
        dav_methods      PUT DELETE MKCOL COPY MOVE;
        dav_ext_methods  PROPFIND OPTIONS;
        dav_access       user:rw group:rw;
        client_body_temp_path /tmp;
        auth_basic        "Login";
        auth_basic_user_file /usr/local/etc/nginx/htpasswd;
}

Make sure that you have created the directory /var/webdav/user/webdav directory for every user.

That’s it. Reload your web server and you can start now with syncing your OmniFocus data with your own Nginx installation.

Making Mailman DMARC compliant

Author: | Categories: Netzwerk No comments

DMARC is available since 2011 as a draft and since March 2015 with RFC 7489. Two years ago, Yahoo and other big e-mail providers have announced, that they will reject e-mails based on DMARC. This is generally a good thing, but it can cause problems for forwarded e-mails (don’t do that, never!) and for mailing lists. If you are running a mailing list, you have to make sure that your mailing list isn’t breaking DMARC. Otherwise, you might experience problems with e-mail delivery.

The reason why mailing lists are breaking DMARC, is SPF and DKIM. DMARC relies on SPF and DKIM and they the cause, why mailing lists are breaking DMARC:

  1. SPF may fail, because the mailing list server is acting as a sending server for a third party domain.
  2. DKIM fails, because the mailing list server changes the e-mail headers.

To avoid DMARC problems on mailing lists, never Mailman’s configuration has to be made DMARC compatible. Make sure, that you are running at least Mailman version 2.1.18.

First, log into the administrative interface of your mailing list and change from_is_list to “Munge From” in the General Options:

mailman_dmarc_settings

This will result in Mailman rewriting (Munge) the From: header with the posters name ‘via the list’ and the list’s address and merge the poster’s address into Reply-To:. Make sure, you change this option on all mailing lists of your Mailman installation.

As a second stop, add the following line your mm_cfg.py and restart Mailman afterwards:

REMOVE_DKIM_HEADERS = 1

With this, Mailman  will remove, if there are any, the DKIM entries within the mail header.

That’s actually it. Your mailing list shouldn’t break DMARC anymore.

Uploading files to My Oracle Support

Author: | Categories: Sun Microsystems / Oracle No comments

When interacting with Oracle Support, it’s quite common that the Oracle engineer asks for a log file, an Explorer Data Collector Output or a Support Bundle. Normally, these files are uploaded through the My Oracle Support web portal, but if you have to upload more than file, this can be a time consuming task.

To make this task easier, Oracle does allow to upload files with curl:

curl -T<file> -u "<user>" https://transport.oracle.com/upload/issue/<sr_number>/

Unfortunately, Oracle does not provide any tool or script to upload easily multiple files. To make my life easier, I’ve wrote this script:

#!/usr/bin/env bash

MYNAME=`basename $0`
USER_NAME=${1}
SERVICE_REQUEST=${2}
UPLOAD_URL=https://transport.oracle.com/upload/issue
FILE_COUNT=`echo ${#}-2 | bc`

printhelp() {
 echo " Usage: ${MYNAME} <User Name> <Service Request> <File Names> ..."
 echo " Example: ${MYNAME} e-mail@example.com 3-12345678901 example.tar.gz"
}

# Print help if not enough options
if [ $# -lt 3 ] ; then
 printhelp
 exit 1
fi

# Add PROXY variable if needed
if [ ${https_proxy} ]; then
 PROXY=${https_proxy}
fi

# Add file names to FILE_NAMES variable
FILE_COUNTX=${FILE_COUNT}
while [ ${FILE_COUNTX} != 0 ]; do
 FILE_NAMES+="${3} "
 shift
 FILE_COUNTX=`echo ${FILE_COUNTX}-1 | bc`
done

# Check if all files are existent
for FILE_NAME in ${FILE_NAMES} ; do
 if [ ! -f ${FILE_NAME} ]; then
  echo .:: ERROR ::.
  echo "==> \"${FILE_NAME}\" does not exist or is not a regular file!"
  exit 1
 fi
done

# Get user password
read -s -p "Password: " USER_PASSWORD
echo

# Upload all files
echo "==> Uploading ${FILE_COUNT} files."
for FILE_NAME in ${FILE_NAMES} ; do
 CURL_OPTIONS="--upload-file ${FILE_NAME} --user ${USER_NAME}:${USER_PASSWORD} ${UPLOAD_URL}/${SERVICE_REQUEST}/"
 echo "==> Uploading ${FILE_NAME}"
 if [ ${PROXY} ]; then
  curl -x ${PROXY} ${CURL_OPTIONS}
 else
  curl ${CURL_OPTIONS}
 fi
done


The Script requires at least Bash version 4.0 and curl.  If you are using a proxy, set the https_proxy variable.

 

Usage

Using the script is really simple. Just specify your My Oracle Support user name (normally your e-mail address), the Service Request number and the files you wish to upload. You can specify as many files as you like.

oracleFileUpload.sh <User Name> <Service Request> <File Name> <File Name> ...

Die perfekte pfSense Firewall / Router für Fiber7

Author: | Categories: FreeBSD, hardware, Netzwerk, pfSense 15 Comments

Die Anforderungen

Wer zu den glücklichen gehört und über einen der begehrten Gigabit Internet Zugänge von Fiber 7 verfügt, der wird irgendwann realisieren, dass man gar kein Gigabit aus der Leitung bekommt, wenn man wenn man den Speedtest Init 7 aufruft. Dabei kann der Flaschenhals nicht nur das “schnelle” 802.11ac WLAN sein (bei 600 MBit/s ist Schluss), sondern auch der Router bzw. die Firewall den man bei sich zu Hause im Einsatz hat. Wenn man nicht nur Pakete von einem Interface zum nächsten schieben will, sondern auch ein paar Firewalling Features benutzen möchte, braucht neben guten Interfaces auch über entsprechende Rechenleistung um tatsächlich Gigabit Durchsatz zu erreichen.

Die guten alten Soekris bzw. Alix Boards eigneten sich hervorragend für einen Kabel- oder DSL Anschluss. Sie hatten keinen störenden Lüfter und wenn man eine Compact Flash Karte verwendet hat, hatte man auch keine Festplatte die kaputt gehen konnte. f

Für Gigabit Glasfaser sind jedoch diese Boards zu langsam. Selbst das neue PC Engines APU2 Board bringt keinen Gigabit Durchsatz mit pfSense.

Also muss etwas neues her, welches die gestiegenen Anforderungen erfüllt. Allerdings ist die Suche nicht gerade einfach, da man für eine Firewall zu Hause doch ein paar spezielle Anforderungen hat:

  • Genügend Rechenleistung
  • Kein Lüfter (lautlos)
  • Für 24/7 Betrieb geeignet
  • 2x Intel Gigabit Interfaces
  • SSD (lautlos)

 

Die Hardware

Nach intensiver Suche, bin ich mit dem DS57U3 von Shuttle fündig geworden:

  • Intel Core i3 CPU
  • mSATA Slot
  • 2.5″ SATA Disk Slot
  • 2x Intel Interfaces, igb & em
  • Metall Gehäuse
  • Für 24/7 Betrieb geeignet

183869f585

Dieser Barebone wird mit einer fest verlöteten Intel Core i3 CPU geliefert, jedoch ohne Memory und SSD bzw. Festplatte. Ich habe mich entschieden, den Barebone mit 4 GB auszubauen, da dies für pfSense vollkommen ausreichend ist. Auch die 30 GB mSATA SSD ist für diesen Anwendungsfall völlig ausreichend.

 

Einkaufliste

Mit folgender Hardware habe ich meine Firewall aufgebaut:

  • Mediakonverter TP-Link MC220L, inkl. SFP & Patchkabel (Init7 / Fiber7)
  • Shuttle Barebone DS57U3 (Brack)
  • Kingston 4 GB DDR3 Memory (Brack)
  • Kingston 30 GB mSATA SSD (Brack)

 

Facebook Videos ruckeln

Author: | Categories: Allgemein No comments

Bei meinem Internetzugang zu Hause habe ich seit einiger Zeit das Problem, dass Videos auf Facebook angefangen haben zu ruckeln. Wie jeder sich das sicherlich gut vorstellen kann, ist das ziemlich unschön und es ist insbesondere noch nerviger, wenn man über einen langsamen Kupferanschluss, sonder über einen schnellen FTTH Anschluss verfügt.

Zuerst dachte ich, dass es ein Routing Issue bei meinem ISP sein könnte. Nach einer Konversation auf Twitter mit meinem ISP (hier nochmals ein “Danke” für den schnellen und kompetenten Support) stellte sich heraus, dass es ein DNS Problem zu sein scheint. Offensichtlich liefert mein lokaler DNS Resolver (ich betreibe aus diversen Gründen meinen eigenen Resolver) in meinem LAN eine andere IP als Antwort, als der Resolver von meinem ISP.

Schauen wir uns dazu mal den DNS Eintrag zu www.facebook.com mal genauer an:

$ dig www.facebook.com AAAA
 
; <<>> DiG 9.9.8-P3 <<>> www.facebook.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4636
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 5
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.facebook.com. IN A
 
;; ANSWER SECTION:
www.facebook.com. 2315 IN CNAME star-mini.c10r.facebook.com.
star-mini.c10r.facebook.com. 38 IN AAAA 2a03:2880:f000:13:face:b00c:0:1823
 
;; AUTHORITY SECTION:
c10r.facebook.com. 2079 IN NS a.ns.c10r.facebook.com.
c10r.facebook.com. 2079 IN NS b.ns.c10r.facebook.com.
 
;; ADDITIONAL SECTION:
a.ns.c10r.facebook.com. 2519 IN AAAA 2a03:2880:fffe:b:face:b00c:0:99
a.ns.c10r.facebook.com. 2511 IN A 69.171.239.11
b.ns.c10r.facebook.com. 2152 IN AAAA 2a03:2880:ffff:b:face:b00c:0:99
b.ns.c10r.facebook.com. 2111 IN A 69.171.255.11
 
;; Query time: 1 msec
;; SERVER: 2a02:168:9800::4d#53(2a02:168:9800::4d)
;; WHEN: So Feb 28 12:14:46 CET 2016
;; MSG SIZE rcvd: 213

Wie man sehen kann, ist www.facebook.com ein CNAME auf star-mini.c10r.facebook.com. Die für c10r.facebook.com zuständigen Name Server sind a.ns.c10r.facebook.com und b.ns.c10r.facebook.com.

Kommt von meinem Resolver die Anfrage für star-mini.c10r.facebook.com an a.ns.c10r.facebook.com, so erhalte ich die IP 2a03:2880:f000:13:face:b00c:0:1823, welche nach Miami führt. So ist es auch nicht weiter verwunderlich, dass die Videos auf Facebook ruckeln, wenn die Daten von der anderen Seite des Atlantiks kommen. Zumal ist die Latenz mit 125 ms recht hoch.

Stelle ich den gleichen Request an Resolver meines ISPs (ns10.init7.net), so erhalte ich die IP 2a03:2880:f01c:21b:face:b00c:0:25de als Antwort. Diese IP steht in Frankfurt und bis dort hin ist die Latenz nur 7 ms.
Die gleiche Antwort erhalte ich auch vom zweiten DNS Resolver meines ISPs, ns20.init7.net.

Der Resolver ns20.init7.net scheint im Datacenter Layer One in Zürich zu stehen, also unmittelbar zu meinem Server, wo auch dieses Blog gehostet ist.

$ traceroute6 -Ia ns20.init7.net
traceroute6 to ns20.init7.net (2001:1620:2777:2::20) from 2001:1620:20a4::9, 64 hops max, 16 byte packets
 1 [AS13030] gw-dogan-init7.dogan.ch 42.454 ms 2.511 ms 7.324 ms
 2 [AS13030] ns20.init7.net 0.556 ms 0.553 ms 0.415 ms

In der Tat wirklich nahe. Kommt nun der Request von meinem Server im Layer One Datacenter, so erhalte ich die IP 2a03:2880:2040:7f21:face:b00c:0:25de zurück und die führt mich in die USA.

Dies ist wirklich spannend. Obwohl bis jetzt alle Requests aus dem gleichen AS und sogar aus dem gleichen Netz kamen, lieferte Facebook mir jedes mal eine andere IP zurück, wobei nur die Antwort der Resolver meines ISP, ns10.init7.net und ns20.init7.net, zum jeweils nächsten Facebook Server verwiesen.

Wie sieht es mit anderen ISPs und Resolvern aus?

Der Google Public DNS Resolver liefert mir die IP 2a03:2880:f008:1e:face:b00c:0:25de zurück (abgefragte aus AS 13030), welche in Mailand steht. 34 ms Latenz. Eine brauchbare Antwort.

Bei Swisscom sieht es ebenfalls ähnlich aus wie bei Init7: Stellt man den Request an den Resolver dns2.bluewin.ch, bekommt man die IP 2a03:2880:f007:1e:face:b00c:0:25de zurück und man landet in Wien. Stellt man den Request direkt an a.ns.c10r.facebook.com, bekommt man 2a03:2880:fffe:b:face:b00c:0:99 zurück und man landet in den USA.

Interessant ist es bei Solnet: Bei einer Anfrage an den Resolver soho.solnet.ch wird man nach Frankfurt (2a03:2880:f01c:21b:face:b00c:0:25de) geschickt. Bei einer direkten Anfrage an a.ns.c10r.facebook.com geht es nach Warschau (2a03:2880:fffe:b:face:b00c:0:99). Die Latenz nach Warschau ist mit 28 ms immer noch in einem sehr guten Rahmen.

Einzig beim Kieler Provider TNG bekommt man immer das gleiche Resultat: Egal ob man den Resolver des ISP oder a.ns.c10r.facebook.com fragt, man wird nach Frankfurt geleitet (2a03:2880:f01c:21b:face:b00c:0:25de).

 

Workaround

Möchte bzw. kann man nicht auf den eigenen Resolver verzichten und möchte nicht mit ruckelnden Videos auf Facebook konfrontiert werden, so kann man als Workaround die Anfragen für facebook.com und fbcdn.net an einen anderen Resolver schicken. Ich habe mich entschieden, die Anfragen an den Resolver meines ISPs weiter zu leiten – dazu ist in der unbound.conf folgende Anpassung notwendig:

forward-zone:
 name: "facebook.com."
 forward-addr: "2001:1620:2777:1::10"
 forward-addr: "2001:1620:2777:1::20"
 
forward-zone:
 name: "fbcdn.net."
 forward-addr: "2001:1620:2777:1::10"
 forward-addr: "2001:1620:2777:1::20"

Wie man sehen kann, konnte ich so die Latenz von 125 ms auf angenehme 7 ms reduzieren:

www_facebook_com_last_864000

Fazit

Bei allen ISPs wurde jeweils a.ns.c10r.facebook.com (der zuständige autoritative DNS server für  10r.facebook.com, Anycast) nach Frankfurt geroutet. Die erhaltene Antwort schickt jedoch den Browser mal in die USA oder mal nach Europa. Wird der Browser in die USA geschickt, kann das zu Problemen beim Abspielen von Videos auf Facebook führen. Dieses Verhalten ist für mich nicht nachvollziehbar und aus meiner Sicht scheint das Content Delivery Network von Facebook zu funktionieren. Einen Fehler mit Anycast oder Routing würde ich jedoch hier ausschliessen.

Generell ist zu empfehlen, wenn immer möglich den Resolver des ISPs zu verwenden.

Diesen Umstand habe ich dem technischen Support von Facebook gemeldet. Updates, werde ich wieder hier in meinem Blog posten.

Update  (1. März 2016)

Daniel Stirnimann hat mich darauf aufmerksam gemacht, dass das von mir beobachtete Verhalten ebenfalls mit Ripe Atlas beobachtet werden kann. In der folgenden Grafik wurde ping6 star-mini.c10r.facebook.com vom Atlas Probe ausgeführt, wobei der Hostname von der Probe selber aufgelöst wurde:
atlas_m1_ownresolve_ping

In der zweiten Grafik wurde ebenfalls ping6 star-mini.c10r.facebook.com ausgeführt, der Hostname wurde jedoch durch den Resolver des ISPs aufgelöst:
atlas_m2_ispresolve_ping

Wie man sehen kann ist das Resultat sehr unterschiedlich. Offensichtlich scheint Facebook Resolver von ISPs und kleinere Resolver anders zu behandeln

 

 

Update  (28. August 2016)

WhatsApp, welches mittlerweile seit gut zwei Jahren zu Facebook gehört, benutzt das Facebook CDN und zeigt das gleiche Verhalten wie Facebook. Auch hier empfiehlt es sich, die Konfiguration des Resolvers anzupassen:

forward-zone:
 name: "whatsapp.com."
 forward-addr: "2001:1620:2777:1::10"
 forward-addr: "2001:1620:2777:1::20"

forward-zone:
 name: "whatsapp.net."
 forward-addr: "2001:1620:2777:1::10"
 forward-addr: "2001:1620:2777:1::20"

Anmerkung zu IPv4 & IPv6

Es gibt keinen Unterschied zu IPv4 und IPv6. Die Antworten zum A und AAAA Record stehen jeweils im Zusammenhang.

Dateien nach UTF-8 konvertieren

Author: | Categories: FreeBSD No comments

Mit iconv können Dateien bequem auf UTF-8 konvertiert werden.

iconv -f <Quellkodierung> -t <Ausgabekodierung> <Datei> > <NeueDatei>

Beispiel:

$ iconv -f ISO-8859-1 -t UTF-8 muttrc > /tmp/muttrc

Solaris 10 Zone von Solaris 10 auf Solaris 11 Hostsystem migrieren

Author: | Categories: Solaris 1 Comment

Solaris 11 unterstützt Solaris 10 branded Zones und bietet so eine Möglichkeit, bestehende Solaris 10 Zonen mit einem geringen Aufwand auf ein Solaris 11 Host System zu migrieren. Obwohl die Zone weiterhin sich wie eine Solaris 10 Zone verhalten wird, macht so eine Migration durchaus Sinn, da sich insbesondere die Administration der Zonen unter Solaris 11 wesentlich vereinfacht und man von neuen Funktionen wie der Netzwerkvirtualisierung profitieren kann. Insbesondere die Netzwerkvirtualisierung vereinfacht vieles, da sich die Zonen nicht. mehr einen IP Stack teilen müssen.

In diesem Beispiel gehe ich nicht darauf ein, wie eine Zone auf eine auf einen exklusiven IP Stack umkonfiguriert wird mittels Netzwerkvirtualisierung. Hierfür möchte ich auf ein hervorragendes Whitepaper von Oracle hinweisen: Exploring Network Virtualization With Oracle Solaris Zones on Oracle Solaris 11 Express

Bevor es los geht, muss man sich einer Einschränkung bewusst sein: Es können nur Full Root Zonen migriert werden!Die mit Solaris 10 eingeführten Sparse Zonen, wo Pakete vererbt wurden und Teile des System geteilt wurden ist in der Theorie sicher eine gute Idee gewesen. In der Praxis stellte sich jedoch heraus, dass der Umgang mit Sparse Zonen sehr problematisch ist, weshalb Oracle mit Solaris 11 nur noch Full Root Zonen unterstützt.

Als Vorbereitung muss auf dem bestehenden Solaris 10 System die Zone heruntergefahren werden. So bald die Zone ausgeschaltet ist, kann daraus ein Backup mit cpio erstellt werden. Hierfür, begibt man sich auf der Shell in das Verzeichnis, wo die Zone installiert ist (z.B. /zones ).

# find dognchgresv01 -print | cpio -oP@ | gzip >dognchgresv01.cpio.gz

Anschliessend kopiert man das File dognchgresv01.cpio.gz auf die neue Solaris 11 Maschine.

Auf der Solaris 11 muss als erstes die Unterstützung für Solaris 10 Branded Zones installiert werden:

# pkg install SUNWs10brand

Anschliessend kann die Zone erstellt und konfiguriert werden:

# zonecfg -z dognchgresv01 
dognchgresv01: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:dognchgresv01> create -t SUNWsolaris10
zonecfg:dognchgresv01> set zonepath=/zones/dognchgresv01/zoneroot
zonecfg:dognchgresv01> add net
zonecfg:dognchgresv01:net> set address=192.168.42.171
zonecfg:dognchgresv01:net> set physical=nge0
zonecfg:dognchgresv01:net> end
zonecfg:dognchgresv01> verify
zonecfg:dognchgresv01> commit
zonecfg:dognchgresv01> exit

Anmerkung
Wenn die bestehende Solaris 10 Zone über ZFS Datasets verfügt, müssen diese getrennt auf das neue System kopiert werden. Wie das geht, habe ich in einem früheren Blog Artikel beschrieben.

Um das Dataset dann einzubinden, muss die Zonenkonfigration entsprechend angepasst werden:

zonecfg:dognchgresv01> add dataset
zonecfg:dognchgresv01:dataset> set name=rpool1/zones/dognchgresv01/dataset01
zonecfg:dognchgresv01:dataset> end

Sobald die Zone konfiguriert ist, kann mit dem cpio Backup die neue Zone erstellt werden:

# zoneadm -z dognchgresv01 attach -a dognchgresv01.cpio.gz

Zum Abschluss muss die migrierte Zone nur noch gebootet werden:

# zoneadm -z dognchgresv01 boot

TLSv1.2 mit Firefox

Author: | Categories: Netzwerk No comments

Firefox unterstützt seit der Version 24 TLSv1.2. Während TLSv1.2 bei Chrome standardmässig aktiv ist, muss man TLSv1.2 bei Firefox manuell einschalten. Leider gibt es hierfür keinen Menupunkt und muss im about:config manuell eingeschaltet werden.

In der URL Bar

about:config

eingeben und die Warnung bestätigen.
Anschliessend nach

security.tls.version.max

suchen.

Die Zahlenkodierung lautet hier:

0: SSL 3.0 
1: TLS 1.0 
2: TLS 1.1 
3: TLS 1.2

Setzt man den Wert von 1 (default) auf 3, spricht Firefox auch TLSv1.2.

Die gleiche Zahlenkodierung gilt auch für security.tls.version.min um die minimale TLS/SSL Version zu setzen. Default ist hier 0, also SSLv3.0.

Quelle: Security.tls.version.*, mozillaZine

Smokeping & nginx auf FreeBSD

Author: | Categories: FreeBSD, Netzwerk No comments

Smokeping wechselte mit der Version 2.5 von mit der auf dem CGI Protkoll basierenden Erweiterung SpeedyCGI auf FastCGI. Somit ist es nun möglich, Smokeping direkt mit nginx über spawn-fcgi zu betreiben ohne die umständlichen Workarounds wie SimpleCGI oder FcgiWRAP.

Für Installation werden folgende Pakete benötigt:

  • www/nginx
  • net-mgmt/smokeping
  • www/spawn-fcgi

Ist Smokeping über /usr/local/etc/smokeping/config konfiguert und gestartet worden, kann es zu Konfiguation des Webserver übergehen.

Der Smokeping FastCGI Prozess wird über spawn-fcgi gestartet und die Kommunikation zum FastCGI Prozess erfolgt über einen Unix Socket /tmp/smokeping-fastcgi.sock. Hierfür sind folgende Einträge in der /etc/rc.conf nötig:

spawn_fcgi_enable="YES"
spawn_fcgi_app="/usr/local/smokeping/htdocs/smokeping.fcgi"
spawn_fcgi_bindsocket="/tmp/smokeping-fastcgi.sock"

Anschliessend kann spawn-fcgi gestartet werden:

# /usr/local/etc/rc.d/spawn-fcgi start

Mit dem folgenden Eintrag in der Server Sektion der /usr/local/etc/nginx/nginx.conf ist Smokeping über die URL /smokeping/ erreichbar:

location /smokeping/ {
         alias /usr/local/smokeping/htdocs/;
         index smokeping.fcgi;
}
location /smokeping/smokeping.fcgi {
         fastcgi_pass unix:/tmp/smokeping-fastcgi.sock;
         include /usr/local/etc/nginx/fastcgi_params;
}