Persönlicher Support von Klaus Buschmann
Zu administrativen Zwecken lege ich häufig an Rechnern von Kunden eigens hierzu lokale Adminkonten an. Damit diese nicht in der Anmeldemaske visuell stören, nutze ich die Anleitung von Apple, um diese aus zu blenden.
Diese Anleitung geht noch weiter. U.a. beschreibt sie die Möglichkeit, den gesamten User Ordner zu verbringen etc…
Zumeist nutze ich einfach diesen Befehl aus dem Artikel:
sudo dscl . create /Users/hiddenuser IsHidden 1
Häufiger benötige ich die Installationsversion auf einem Stick, besonders dann, wenn die Internetanbindung sehr langsam ist.
Hierzu nutze ich die Anleitung direkt von Apple. Sie fasst die nötigen Schritte kurz und bündig zusammen.
Gelegentlich ist es sinnvoll, die lokale user ID (UID) eines OS X Kontos zu ändern. Standardmäßig lautet diese 501 bzw. 502 aufwärts.
Im Zusammenspiel mit Office von Microsoft und dem Speichern auf Netzwerklaufwerken gibt es u.U. Probleme. Hier ist der Hintergrund genauer beschrieben.
Eine der Lösungen ist die Vergabe von individuellen. lokalen UIDs.
Hierzu nutze ich diese Anleitung! Vielen Dank an den Autor Roman
Kurzzusammenfassung für mich als Checkliste:
# find -xP / -user 501 -print0 | xargs -0 chown -h 1051
Schon länger beobachte ich, dass VPN Tunnel, die von OS X 10.11 (Beta und Final) via IPSec zu einer FRITZ!Box aufgebaut werden und der Provider Unitymedia (ex. Kabel BW) ist, zwar eine Verbindung herstellen, darüber aber kein nutzbarer Traffic möglich ist. Unter iOS 8 und OS X 10.10.x war das noch möglich.
Auch eine Neukonfiguration der Tunnel bringt keine Besserung. Die Verbindung lässt sich zwar aufbauen, doch eine Kommunikation nicht herstellen.
Dieser Artikel beschreibt das Verhalten genauer. Eine Lösung ist mir bis heute (03.10.2015) nicht bekannt.
Die FRITZ!Box Firmware ist (leider) noch 6.04. Darauf haben wir Unitymedia-Kunden ja leider keinen direkten Einfluss. Die Firmware wird von Unitymedia vorgegeben/aktualisiert.
Wer hat ähnliches Verhalten beobachtet bzw. weitere Infos?
Edit: Dieter aus Marl verwies mich auf diesen Thread beim ip-phone-forum.de, indem die Poster ausführlicher und detaillierter (insb. salamihawk) auf die Umstände eingehen. Vielen Dank hierfür.
Kurz nach der Präsentation von Apple im Bill Graham Civic Auditorium San Francisco am 09.09.2015 steht nun die OS X El Capitan Golden Master Version des zukünftigen Betriebsystems für Teilnehmer des „Apple Beta Software-Programm“.
Sie kann einfach über den App Store (Gekaufte Artikel) geladen werden.
Zudem verschickte Apple an iOS Entwickler eine Einladung zur Voranmeldung/Bestellung eines „Apple TV Developer Kit“.
Seit heute gewährt Apple in einer sog. Public Beta Vorabversion ihres zukünftigen OS X 10.11 Betriebssystems namens El Capitan einen ersten Einblick für ein breites Publikum.
Ich habe heute einige Stunden damit verbracht und bin positiv angetan und angenehm überrascht über die spürbare Geschwindigkeitsverbesserungen über weite Bereiche des Systems.
Apple kündigte auf seiner Entwicklerkonferenz bereits an, dass durch Integration der Grafikengine „Metal“ deutliche Geschwindigkeitsgewinne erreicht würden. Mein erster Eindruck: Apple hat nicht zu viel versprochen.
Das System soll noch nicht für produktiven Einsatz genutzt werden – klar. Es handelt sich noch um eine Betaversion, bei der noch nicht akzeptabel Bugs und Fehler auftreten können.
Dennoch: Ich wagte, natürlich nach ordentlichen Backups (via Time Machine aber auch via 1zu1 bootfähigen Partitionen), das Upgrade über mein bestehendes System – mit vielzähligen Programmen, Tools und Treibern. Das Upgrade lief, frei von Fehlermeldungen, durch. El Capitan „fühlt“ sich bereits jetzt sehr flüssig an. Ich habe entschieden, zunächst bereits bei diesem System zu bleiben und damit meine tägliche Arbeit zu verrichten.
Bisher hatte ich auf meinem iMac 5K ein Darstellungsproblem, bei dem z.B. Mission Control ins „Stottern“ kam und auch div. andere Darstellungsprobleme beim Arbeiten mit Fenstern (vor allem bei deren Animation) auftraten. Die Foren bei Apple schildern die div. Probleme umfangreich.
Seit dem Upgrade auf die Beta sind diese Darstellungsschwierigkeiten – zu mindest hier auf meinem System – vollständig verschwunden.
God job, Apple!
Ab der OS Version 10.11 (El Capitan) verschwindet die Möglichkeit, über das Festplattendienstprogramm die Volumen-Zugriffsrechte der Systempartition reparieren zu lassen. Dies findet ab dann automatisch nach Installationen statt. So schreibt es ein Artikel der aktuellen ct´2015, Heft 15, auf Seite 48.
Manuell lässt sich dieser Vorgang natürlich nach wie vor über das Terminal mit folgendem Befehl starten:
sudo diskutil repairPermissions /
Wobei das / für die aktuelle Partition steht. Soll ein anderes Volumen repariert werden, so muss hier der Pfad angegeben werden. Z.B.: /Volumes/anderes
Edit: In der public beta Version 4 von 10.11 ist dieser Befehl nicht mehr anwendbar.
Bei einigen Tarifen bietet KabelBW bzw. jetzt Unitymedia mehrere statische IP Adressen an.
Diese müssen über deren Portal aktiviert werden. Hierzu sind die MAC Adressen der WAN-Anschlüsse des bzw. der Router ein zu tragen. Jeder MAC Adresse kann EINE statische IP Adresse zugewiesen werden.
Üblicherweise bekommt der Kunde bei einem Business-Anschluss mit 5 statischen IP Adressen ein Cisco Modem. Dahinter wird dann ein Router bzw. eine Firewall angeschlossen.
In unserem Fall betreiben wir eine Sophos Firewall daran. Diese, wie sehr viele andere Router/Firewalls, bietet zwar die Möglichkeit, virtuelle Adressen am WAN Port zu definieren. Das bringt uns unserem Wunschszenario, mehrere IP Adressen an den WAN Port der Firewall zu leiten, aber nicht näher.
Unser Weg:
Hinter dem Cisco-Modem greifen wir das Internetsignal nicht direkt mit der WAN-Schnittstelle der Sophos ab (was nur eine MAC hätte), sondern schalten einen 5-Port Gigabit Switch dazwischen. Nun leiten wir zwei WAN-Leitungen an zwei Schnittstellen der Firewall, welche wir jeweils als WAN (WAN1 und WAN2) konfigurieren. Somit verfügen wir nun über ZWEI MAC Adressen, die wir den jeweils gewünschten IP Adressen im Portal von Unitymedia zuordnen. Nun erhalten wir auch die entsprechenden Adressen in der Sophos Firewall.
Wir möchten einen FTP Server aus dem LAN heraus so betreiben, dass dieser über die 2. statische IP Adresse erreichbar ist UND auch darüber hinaus ins Internet gelangt. Leider lässt sich nur EINE der WAN-Anschlüsse als Default Gateway definieren. Routing Policies etc. verhalfen uns nicht, dieses Szenario um zu setzen.
Was hilft ist die Konfiguration der beiden WAN-Schnittstellen unter Interfaces & Routing/Interfaces als Uplink balance:
Auf diese Weise können beide nun als Default Gateway fungieren.
Die Maskierung sieht dementsprechend auch einfach aus (man beachte „Uplink Interfaces“):
Zu guter letzt, und das bringt den gewünschten Split:
Unter Interfaces & Routing / Multipath Rules kann nun dem einzelnen FTP Server die WAN2 Schnittstelle zugewiesen werden (zweiten Regel). Das restliche LAN hingegen bekommt aber die WAN1 angefacht (erste Regel):
Ein Kunden muss auf bestimmte Webdienste unter seiner statischen IP Adresse (die der Firma) gelegentlich auch von unterwegs zugreifen. Nur über diese Adresse kommend erhält er dort Einlass.
Er könnte über TeamViewer von unterwegs auf einen Rechner in der Firma zugreifen und darüber dann den Browser bedienen.
Wir entschieden uns aber, seine vorhandene Sophos UTM Firewall zu nutzen.
Folgendermaßen ging ich vor:
Einrichtung einer SSL-VPN Verbindung. Diese hat jedoch zunächst die Eigenschaft, einen split-tunnel zu erstellen, sprich: Nur der Trafic für das entfernte LAN wird durch den Tunnel geleitet, andere Anfragen, so auch die Web-Aufrufe (die eigentlich über die Firmen-IP erfolgen sollen), würden direkt vom Client ins Web gleitet.
Um dies zu unterbinden genügt es, in der Konfiguration unter „Lokale Netzwerke“ des SSL-VPN Profiles (Fernzugriff/SSL) in der Sophos UTM „Any“ für das erlaubte Netzwerk zur VPN Nutzung ein zutragen. Damit veranlasst die Sophos, dass der gesamte Trafic durch den Tunnel geroutet wird. Ein evtl. bereits eingerichteter VPN Client muss mit neu heruntergeladenen Konfig-Daten aktualisiert werden. Vergesst die automatischen Firewall-Regeln nicht oder aber setzt manuelle Regeln für das neue Netzwerk.
Nicht zu vergessen ist, dass wir in der Firewall nun das zugehörige VPN-SSL Netzwerk noch maskieren müssen, damit das Netzwerk auch „raus“ ins Internet kann.
Notiz für mich als Gedankenstütze – und für alle anderen, die es interessiert:
Migration des Collaboration Service (Wiki Server) von 10.6.8 Snow Leopard nach 10.8.4 Mountain Lion Server