Das siebte Update der 6´er Reihe ist da

Red Hat Enterprise Linux 6.7 erscheint rund 5 Jahre nach der Erstveröffentlichung und wird offiziell noch 2 Jahren, optional noch weitere 5 Jahre gepflegt.

RHEL 6.7 verwendet im Gegensatz zum aktuellen 7´er Zweig immer noch einen Kernel 2.6.32, der allerdings gegenüber der Version von RHEL 6.0 mittels Patches funktional stark erweitert wurde, unter anderem mit Treibern zur Unterstützung aktueller Hardware, wie etwa dem iwlwifi-Treiber, welcher jetzt Intels 7265/3165 (Stone Peak) Chips unterstützt.

Weitere Neuerungen

RHEL 6.7 unterstützt zudem jetzt LVM-Cache (Logical Volume Management)vollständig. Mit der Funktion können Nutzer SSDs als logischen Datenträger-Cache für langsamere Storage-Geräte verwenden. LVM-Cache war in der Vorgängerversion noch als Technologievorschau eingestuft. Neu sind auch Erweiterungen im Code des Identity Managements (SSSD). Noch als Technologie-Vorschau eingestuft ist der clufter-Support. Damit können Admins Cluster-Konfigurationen analysieren und migrieren. Neu in RHEL 6.7 ist auch die Unterstützung von Linux Containers, allerdings ebenfalls als Vorschau eingestuft.

Mehr Sicherheit

In puncto Sicherheit können RHEL-Anwender jetzt festlegen, dass mobile Speichergeräte nur im Lesemodus angeschlossen werden können, um Datendiebstahl von mobilen Speichermedien zu verhindern. So ist es z. B. möglich, USB-Sticks den Read-Only-Modus aufzuzwingen. Ebenfalls neu bei den Sicherheitsfunktionen ist die Security Content Automation Protocol Workbench (SCAP). Sie arbeitet nun als Security-Scanner und lässt sich jetzt auch grafisch einrichten. RHEL 6.7 bringt zudem mit lshw ein Tool Hardwareanalyse mit. Ferner können RHEL-Nutzer mit den neuen Service redhat-access-insights Probleme proaktiv erkennen und ggf. lösen, bevor sie sich auf kritische Geschäftsprozesse auswirken.

Wie üblich können Red-Hat-Kunden mit einer gültigen Subskription RHEL 6.7 ab sofort via Red Hat Network (RHN) beziehen.

Nano-Server: Grundlagen und Funktionen

Bei der Nano-Installation handelt es sich aber um keine spezielle Edition von Windows Server 2016, sondern um eine spezielle Installationsvariante, genauso wie bei der Core-Installation. Auf diesen Sachverhalt legt Microsoft sehr viel wert. Windows-Treiber lassen sich auf Nano-Server also problemlos nutzen. Außerdem plant Microsoft die Integration von Nano-Servern in System Center 2016. Auch ein Virenschutz soll integrierbar sein. Nano-Server unterstützen natürlich generell alle APIs, die mit Windows Server 2016 kompatibel sind. Nur APIs die Zugriff auf den Desktop oder lokale Verwaltungsprogramme erfordern werden nicht unterstützt. Generell verhalten sich die Server also wie herkömmliche Server auch. Der Zugriff durch die Anwender erfolgt transparent. Entwickler müssen also keine speziellen Client-Anwendungen programmieren, mit denen Anwender auf Nano-Server zugreifen können.

Auch wenn Nano-Server deutlich eingeschränkt sind, unterstützen Sie wichtige Windows-Funktionen wie Storage und auch Scale-Out File-Server (SOFS), Clustering,  CoreCLR und ASP.NET 5. Auch PowerShell Desired State Configuration (DSC) lässt sich in Zusammenhang mit Nano-Servern nutzen. Gerade hier ist die Technik sogar sehr sinnvoll, da Sie mehrere Nano-Server auf einmal schnell und einfach auf einen zentralen sicheren Stand bringen können. Die PowerShell ist das zentrale Verwaltungswerkzeug für Nano-Server. Da die Server vor allem für Cloudszenarien gedacht sind, unterstützen sie auch viele Programmiersprachen, zum Beispiel Chef, Go, Java (OpenJDK), MySQL, Nginx, Node.js, OpenSSL, PHP, Python 3.5, Redis, Ruby 2.1.5, und SQLite Visual Studio 2015 ist vollständig kompatibel mit Nano-Server und kann Anwendungen direkt auf diesen Servern bereitstellen. Entwickler können mit Visual Studio über das Netzwerk auch nach Fehlern in Anwendungen suchen (Remote Debugging). Beim Entwickeln für Nano-Server weist Visual Studio darüber hinaus auf API-Zugriffe hin, die mit Nano-Servern nicht kompatibel sind.

Die Nano-Installation wird keine Setup-Option sein, wie die Installation von Core-Servern. Nano-Server werden als Image bereitgestellt.

Einfache Schaltung eliminiert Offset in Sensorbrücken

Sensorsignale sind in der Regel sehr klein, weswegen man sie mit Instrumentenverstärkern sehr stark verstärkt. Wir stellen eine nachjustierbare, kostengünstige Schaltung für die Industrie vor, die daraus resultierende Fehler eliminiert.

Mit Instrumentenverstärkern lassen sich von Sensoren erzeugte elektrische Signale aufbereiten, damit man sie anschließend digitalisieren, speichern oder zur Steuerung von Prozessen verwenden kann.

Da Sensorsignale normalerweise sehr klein sind, muss der Instrumentenverstärker mit hoher Verstärkung arbeiten. Auch können sich Sensorsignale auf einer hohen Gleichtaktspannung oder eingebettet in einer hohen Gleichspannungs-Offsetspannung befinden.

Man stelle sich einen Brückenverstärker mit einfacher Versorgungsspannung vor, bei dem eine Spannung von 3,3 V zur Anregung der Brücke und zur Versorgung des Verstärkers verwendet wird. Der Messbereich des Brückenausgangs beträgt ±15 mV. Die Offsetspannung kann im Bereich von ±25 mV liegen. Um die gewünschte Empfindlichkeit zu erreichen, muss die Verstärkung 100 betragen.

Der Eingangsbereich des A/D-Wandlers beträgt 0 bis 3,3 V. Der Ausgang der Brücke kann positiv oder negativ sein. Somit wird der Ausgang auf die mittlere Versorgungsspannung oder 1,65 V bezogen. Bei einer einfachen Verstärkung von 100 würde der Offset dafür sorgen, dass der Verstärkerausgang zwischen –0,85 und +4,15 V variiert. Dies übersteigt die Versorgungsspannung.

Bild 1: Schaltung zur Beseitigung von Offset, modifiziert für den Betrieb mit einer unipolaren Versorgung. (Bild: ADI)
Bild 1: Schaltung zur Beseitigung von Offset, modifiziert für den Betrieb mit einer unipolaren Versorgung.

Die Schaltung in Bild 1 löst dieses Problem. Als Brückenverstärker A1 dient der Instrumentenverstärker AD8237 mit indirekter Stromrückkopplung. Der Verstärker A2 mit den Widerständen R4 und R5 stellt den Null-Pegel Ausgang von A1 auf die mittlere Versorgungsspannung ein. Der 8-Bit-D/A-Wandler AD5601 stellt den Ausgang so ein, dass die Brückenoffsetspannung über RA Null wird. Das Ausgangssignal des Verstärkers wird anschließend mit dem 12-Bit-A/D-Wandler AD7091 digitalisiert.

Die Ausgangsspannung des D/A-Wandlers kann sich zwischen 0 und 3,3 V oder mit ±1,65 V um die Referenzspannung von 1,65 V bewegen. Mit UA(max) = 1,65 V und UIN(max) = 0,025 V beträgt RA = 65,347 kΩ. Mit einer Widerstandstoleranz von 1% ergibt sich der nächste verfügbare Wert zu 64,9 kΩ.

Dies lässt kein Spielraum für Fehler, die durch die Genauigkeit der Quelle und Temperaturunterschiede verursacht werden. Somit sollte man einen preiswerten, normalerweise gut verfügbaren 49,9-kΩ-Widerstand verwenden. Der Nachteil ist eine reduzierte Einstellungsauflösung und eine geringfügig höhere Offsetspannung nach der Einstellung.

Bei R1 = 1 kΩ und R2 = 100 kΩ beträgt die Nennverstärkung 103. Wird ein Wert näher am Zielwert von 100 gewünscht, reduziert man den Wert von R2 um etwa 3% auf 97,6 kΩ. So erhält man eine Nennverstärkung von 100,6.

Der gesamte Offset-Einstellbereich ergibt sich aus dem Spannungsteiler, der durch RA und der Parallelschaltung der Widerstände R1 und R2 gebildet wird. Er lässt sich mit Gleichung 1 berechnen:

Gleichung 1
Gleichung 1

Damit ergibt sich: [0,99 kΩ / (0,99 kΩ + 49,9 kΩ)] ±1,65 V = ±32,1 mV. Eine Anpassung von ±32,1 mV über den maximalen Brückenoffset von ±2 5mV liefert eine zusätzliche Anpassungsreserve von 28%.

Mit einem 8-Bit-D/A-Wandler beträgt die Schrittweite der Anpassung

Das entspricht 64,2 mV / 256 ≈ 250 µV. Mit einer Anpassungsauflösung von 250 µV ergibt sich am Ausgang ein maximaler Offset von 12,5 mV.

Gleichung 2
Gleichung 2

Die Werte von R3 und C1 können aus dem Datenblatt des A/D-Wandlers entnommen werden. Für das 1 MSample/s schnelle Wandlermodell AD7091 betragen diese Werte 51 Ω und 4,7 nF. Kombinationen mit größeren Widerstands- und Kondensatorwerten kann man verwenden, um bei niedrigeren Abtastraten das Rauschen und Aliasing-Effekte zu reduzieren.

Ein weiterer Vorteil der im Bild 1 gezeigten Schaltung besteht darin, dass die Einstellung des Brückenoffsets in der Produktion oder bei der Installation erfolgen kann. Falls Umwelteinflüsse, Sensor-Hysterese oder Langzeitdrift den Wert des Offsets beeinträchtigen, kann die Schaltung nachjustiert werden.

Wegen seines echten Rail-to-Rail Eingangs arbeitet der AD8237 am besten in Brückenschaltungen, die mit sehr niedrigen Spannungen versorgt werden. Für herkömmliche Industrieanwendungen, die höhere Versorgungsspannungen verlangen, ist der AD8420 eine gute Alternative. Dieser Instrumentenverstärker mit indirekter Stromgegenkopplung arbeitet mit Versorgungsspannungen von 2,7 bis 36 V und nimmt 60% weniger Strom auf.

Die Autoren: Gustavo Castro, Scott Hunt, Analog Devices.

Microsoft Advanced Threat Analytics

Microsoft bietet mit Microsoft Advanced Threat Analytics (ATA) eine Erweiterung für seine Enterprise Mobility Suite (EMS). Aufgabe des Systems ist das Erkennen von verdächtigen Aktionen im Netzwerk, die von Angreifern wie Viren oder Hackern durchgeführt werden. Bei ATA handelt es sich um eine Serverlösung, die Sie im lokalen Netzwerk, von Microsoft gerne als On-Premise bezeichnet, installieren.

Mit ATA können Sie aber auch die Zugriffe auf Microsoft Azure oder Office 365 überwachen. Im Fokus von ATA stehen Angriffe auf Benutzeranmeldedaten. Daher überwacht die Lösung vor allem Active Directory-Domänencontroller.

Der Dienst soll aber nicht nur Smartphones oder Tablets schützen, sondern auch interne Netzwerke in Active Directory-Strukturen sowie in Microsoft Azure und Azure Active Directory. Microsoft will mit ATA den Unternehmen ein Werkzeug an die Hand geben, um Netzwerke vor Angriffen zu schützen, die durch eine Vielzahl an Zugriffsmöglichkeiten stattfinden können. In den meisten Unternehmen können Anwender über immer mehr Geräte und Anbindungen auf Daten des Unternehmens zugreifen. Nur durch ein zentrales Tool wie ATA ist es dabei möglich einen Überblick zu erhalten und Angriffe schnell und einfach zu entdecken.

Die Einrichtung des Tools ist sehr einfach, die Analyse des Netzwerkes erfolgt sofort nach der Installation. Sie installieren einen Serverdienst, der das Netzwerk überwacht und einen zentralen Sammeldienst, der die Informationen aufbereitet. Die Installation kann auf dedizierten Servern erfolgen, oder auf einem gemeinsamen Server, die Daten analysiert und die Ergebnisse auch gleich aufbereitet.

Opensuse treibt Umbau seiner Distribution voran

Leap 42.1 ist der Name (einschließlich Version) einer für Herbst diesen Jahres geplanten, völlig neu strukturierten Opensuse Distribution.

Das „Problem“ von Opensuse in Form sinkender Popularität ist die im Vergleich zu Fedora, Ubuntu & Co fehlende Profilschärfe. Während beispielsweise Fedora für das Verwenden stets hochaktueller Linux- und Open-Source-Technologien steht (nebenbei dient Fedora auch als Experimentierfeld der Red-Hat-Entwickler), Ubuntu vor allen Heimanwender oder Linux-Einsteiger mit möglichst einfacher Bedienung in Form eines eigenen (Unity)-Desktops lockt und Debian der reinen Open-Source-Lehre huldigt, war schon lange nicht mehr klar erkennbar, wofür Opensuse eigentlich steht.

Tumbleweed gräbt Opensuse das Wasser ab

Opensuse hat außerdem das Problem, das Rolling-Release-Distributionen immer populärer werden. Das gilt zwar auch für die anderen Vertreter, bei Opensuse hat man sich allerdings mit der parallelen Pflege von Tumbleweed und Factory Konkurrenz im eigenen Haus gemacht.

So kämpft Opensuse mehr als andere Hersteller, die sich relativ früh klarer positioniert hatten, mit unzufriedenen Nutzern an zwei Fronten. Vielem Anwendern war Opensuse im Vergleich mit Tumbleweed nicht aktuell genug. Auf der andere Seite ist vielen Nutzern der Unterstützungszeitraum der regulären Variante von rund 18 Monaten zu kurz, sieht man mal von Evergreen-Releases ab.

Tumbleweed und Factory

Das Problem verschärft sich dadurch, dass inzwischen auch viele Entwickler zu Tumbleweed gewechselt sind. Das von Kernel-Entwickler Greg Kroah-Hartman initiierte Tumbleweed war bis November letzten Jahres neben Opensuse-Factory einer von zwei aktiv gepflegten Rolling-Release-Zweigen, ein Luxus, der typisch für die Uneinigkeit im OpensuseTeam war.

Erst mit Erscheinen von Opensuse 13.2 im November letzten Jahres führte man Tumbleweed und Factory unter neuem Namen Tumbleweed zusammen. Zwar hatte sich Kroah-Hartman seinerzeit selbst gewünscht, Tumbleweed werde so bald wie möglich überflüssig und in Factory aufgehen, stand letztendlich aber auch der umgekehrt eingetretenen Variante positiv gegenüber.

SLE + X = Leap

Die übrig gebliebenen Entwickler der regulären Opensuse-Variante hatten darauf hin beschlossen, ein neues Opensuse mit geänderter Ausrichtung unter neuen Namen Opensuse Leap 42 zu kreieren, deren erster Meilenstein jetzt als Etappenziel der für den Spätherbst geplanten stabilen Variante Leap 42.1 vorliegt.

Kernidee der „neuen Ausrichtung“ ist eine Basis-Distribution, die sich aus Paketen der kommerziellen Variante Suse Linux Enterprise (SLE), ergänzt um aktuelle Paketen und Erweiterungen definiert. Um das zu ermöglichen, sollen Teile der Quellen von Suse Linux Enterprise (SLE) in den Opensuse-Build-Service (OSB) eingespielt werden.

Offiziell soll das stabile Leap 42.1 auf der SUSECon im November in Amsterdam veröffentlicht werden und beispielsweise auf Basis eines Kernel 4.1 unter anderem GNOME 3.16, KDE Plasma 5 und Firefox 38 mitbringen, um nur ein paar Beispielpakete zu nennen. Insgesamt enthält der erste Meilenstein 56.500 Binärpakete. Opensuse 13.2 brachte es im Vergleich auf 71.750 Paketen.

Leap ausprobieren

Laut Aussage der Opensuse-Entwickler sollen alle Ausgaben von Leap 42.x auf SLE 12 basieren, während Leap 43 dann auf SLE 13 aufsetzen wird. Wer bereits jetzt einen Blick auf die runderneuerte Opensuse-Distribution werfen will, kann ein rund 3GB großes DVD-Image des ersten Meilensteins von der Downloadseite herunterladen. Weitere Informationen gibt es auf der Wiki-Seite des Leap-Projektes.

SCCM-Netzwerk konfigurieren und testen

Beim Einsatz von SCCM im Netzwerk müssen auf den Client-Computern und Servern verschiedene Firewall-Regeln erstellt werden. Damit diese Konfiguration konsistent und sicher umgesetzt wird, verwenden Sie am besten eine Gruppenrichtlinie:

  1. Erstellen Sie dazu zunächst in der Gruppenrichtlinienverwaltungskonsole auf einem Domänencontroller oder einer Arbeitsstation mit den Remoteserver-Verwaltungstools eine neue GPO mit der Bezeichnung „SCCM“.
  2.  Öffnen Sie die Bearbeitung dieser Richtlinie und navigieren Sie zu: Computerkonfiguration\Richtlinien\Windows-Einstellungen\Sicherheitseinstellungen\Windows-Firewall mit erweiterter Sicherheit.
  3. Erstellen Sie über das Kontextmenü von Eingehende Regel und erstellen eine neue Regel.
  4. Wählen Sie als Option Vordefiniert und wählen Sie Datei- und Druckerfreigabe. 
  5. Bestätigen Sie die weiteren Fenster des Assistenten und wählen Sie Verbindung zulassen.
  6. Erstellen Sie die gleiche Regel auch über Ausgehende Regeln.
  7. Erstellen Sie eine weitere eingehende Regel und wählen dieses Mal Vordefiniert\Windows-Verwaltungsinstrumentation.
  8. Schließen Sie die Richtlinie und verknüpfen Sie diese mit dem Container in dem sich die Computerkonten der Rechner befinden, die Sie mit SCCM verwalten, am besten mit der ganzen Domäne.
  9. Erstellen Sie danach eine weitere Richtlinie. In dieser nehmen Sie ebenfalls Firewall-Änderungen vor. Diese gelten aber nur für die beteiligten SCCM- und Datenbank-Server:
  10. Erstellen Sie eine eingehende Regel und wählen Sie dieses Mal Port.
  11. Öffnen Sie die Bearbeitung dieser Richtlinie und navigieren Sie zu: Computerkonfiguration\Richtlinien\Windows-Einstellungen\Sicherheitseinstellungen\Windows-Firewall mit erweiterter Sicherheit.
  12. Erstellen Sie eine eingehende Regel und wählen Sie dieses Mal Port.
  13. Wählen Sie TCP als Option und den Port 1433 vor.
  14. Schließen Sie den Assistenten ab und lassen Sie den Zugriff zu diesem Port zu.
  15. Erstellen Sie eine weitere Regel zum TCP-Port 4022, ebenfalls als eingehende Regel.
  16. Verknüpfen Sie die GPO mit dem Container in dem sich die Server-Computer befinden.

Um die Regeln zu testen, geben Sie auf einem der Computer gpupdate /force ein. Wurden die Richtlinien umgesetzt, starten Sie rsop.msc. Klicken Sie auf Administrative Vorlagen\Zusätzliche Registrierungseinstellungen. Sie sehen jetzt die neuen GPOs und die umgesetzten Regeln.

Das Hyper-Projekt erlaubt das Verwenden von Docker-Images unter verschiedenen Hypervisoren

Die vom XenProject bekannt gegebene Partnerschaft mit dem chinesische Unternehmen Hyper hat zum Ziel, die Vorteile der Anwendungsvirtualisierung mit Docker mit den Vorteilen vollwertiger, unter einem Hypervisor ausgeführter virtueller Maschinen zu vereinen.

Die Grenzen von Docker und virtuellen Maschinen

Mit Docker-Containern lassen sich relativ einfach einzelne Anwendungen virtualisieren und damit portabel machen. Aufgrund des geringen Overheads ist zudem die „Packungsdichte“ auf dem Container-Host bedeutend höher, als bei echten virtuellen Maschinen.

Dafür haftet der Container-, bzw. Betriebssystem-Virtualisierung immer noch der Makel an, dass sich die einzelnen Container nicht oder nur mit großen Aufwand sicher voneinander isolieren lassen. Echte, unter einem Hypervisor ausgeführte virtuelle Maschinen verschlingen dafür unnötig viele Ressource, wenn es nur um das Bereitstellen einzelner Anwendungen geht.

Was Hyper besser machen will

Das chinesische Unternehmen Hyper sieht in der eingeschränkten Isolationsfähigkeit von Docker-Container untereinander, sowie zwischen Containern und Host-System ein großes Sicherheitsproblem . Mit einer eigenen Docker-Laufzeitumgebung will es Hyper künftig ermöglichen,Docker-Images unter beliebigen Hypervisoren auszuführen.

Der Hypervisor sorgt dann im Hyper zusammen mit der Hardwareunterstützung für die gewünschte Isolation, während Hyper von Docker die Portabilität, die schnelle Bootzeit, die kleine Imagegröße und den Umstand, dass Image unveränderlich sind und nicht angepasst werden müssen, erbt.

Dafür mangelt des derzeit noch an der Kompatibilität, der Leistungsfähigkeit und am Reifegrad des noch jungen Projektes. Die erste Version 0.1 ist am 25. Mail dieses Jahres erschienen, aktuell ist die Version 0.2.1 von 06. Juli, die als ersten Hypervisor Xen 4.5 unterstützt.

Hyper ist in Googles Go geschrieben und steht unter der Apache-Lizenz 2.0. Die Installation ist auf der Projektseite ausführlich beschrieben, setzt aber Docker ab 1.5 und Qemu 2.0 voraus. Der Sourcecode kann von Github heruntergeladen werden.

SCCM 2012 R2 sichern und Wartungstasks aktivieren

Um SCCM 2012 R2 effizient zu sichern, sollten Sie in der SCCM-Verwaltungskonsole einige Einstellungen anpassen. Dazu öffnen Sie zunächst den Bereich Verwaltung\Standortkonfiguration\Standorte. 

Markieren Sie den Standort für den Sie Server sichern wollen.  Klicken Sie danach auf Einstellungen\Standortwartung.

Im neuen Fenster sehen Sie verschiedene Wartungstasks des Standortes die aktiviert oder eben nicht aktiviert sind. Um SCCM effizient zu sichern, aktivieren Sie zunächst den Wartungstask Standortserver sichern. 

Nachdem der Task aktiviert ist, konfigurieren Sie diesen zunächst. Klicken Sie dazu auf Bearbeiten. Im neuen Fenster aktivieren Sie zunächst die Sicherungsaufgabe für SCCM und klicken auf Pfad festlegen.

Jetzt können Sie ein Verzeichnis festlegen, indem SCCM wichtige Daten ablegt. Dieses lokale Verzeichnis sollten Sie natürlich mit der Datensicherung des Servers mit sichern lassen. Legen Sie im Fenster auch den Zeitpunkt fest, wann die Datensicherung erfolgen soll. Verwenden Sie als Pfad zur Sicherung am besten eine Freigabe im Netzwerk. 

Nachdem Sie die Konfiguration vorgenommen haben, sichert der Wartungstask automatisch die wichtigsten SCCM-Daten in dem von Ihnen festgelegten Verzeichnis.

In den Einstellungen der Wartungstasks können Sie die Sicherung aber auch manuell durchführen lassen. Rufen Sie dazu die Systemdienste auf dem Server auf (services.msc) und suchen Sie den Systemdienst SMS_SITE_BACKUP. Starten Sie diesen Dienst, wird die Sicherung durchgeführt, und der Dienst danach wieder beendet. Durch das Starten des Dienstes können Sie also jederzeit manuell eine Datensicherung durchführen lassen.

Öffnen Sie auch über das CMTrace-Tool die Logdatei smsbackup.log. Hier sehen Sie den Status der Datensicherung, und ob die Sicherung funktioniert.

Suse Linux Enterprise 11 SP4 verbessert Sicherheitsfunktionen

Suse pflegt wie Red Hat stets mindestens drei Hauptlinien seiner Unternehmens-Distribution und bietet seinen Kunden stets mindestens 7 Jahre, optional auch 10 Jahre Produktpflege. So genießt z. B. Suse Linux Enterprise 10, für das ebenfalls 4 Service Packs veröffentlicht wurden, auf Wunsch noch Support bis Juli nächsten Jahres. Jetzt ist auch SLE 11 beim vierten Service-Update angelangt und bietet SLE-11-Nutzern offiziell Produktpflege bis zum 31.03.2019, sowie optional bis zum 31.03.2022. Die aktuelle Version SLE 12 wird mindestens bis zum 31.01.2024, optional bis zum 31.10.2027 gepflegt.

Bessere Hardwareunterstützung

Mit dem jetzt veröffentlichten Service-Pack 4 unterstützt die „11er-Reihe“ nun auch neuere Prozessoren wie z. B. die Intel Xeon E7-8800/4800-v3-Familie oder IBMs z13 und IBM Power8-Systeme. Außerdem bringt das SP4 zwei komplett neue Module mit.

Mit dem Public Cloud Modul erweitern Admins SLE um Tools für das Erstellen und Verwalten von Cloud-Images. Darüber hinaus erlaubt das neue Security Modul den Aufbau einer HTTPS-Infrastruktur auf Basis von TLS 1.2.

Aktualisierte Software

Bei der von SLES 11 SP4 verwendeten Kernel-Version 3.0 ändert sich wie üblich nicht viel, allerdings haben die Entwickler den Kernel mittels Patches mit zahlreichen Erweiterungen ausgestattet. Ferner wurden eine Reihe von Software-Paketen aktualisiert, etwa PostgreSQL, NTP-Server, OpenSSH, virt-manager oder Xen und systemnahe Komponenten, wie Yast, Zypper, Binutils oder GDB. Darüber hinaus wird für kryptografische Prüfsummen jetzt SHA256 statt SHA verwendet, z. B. für die Validierung der Paketquellen.

Weitere Einzelheiten finden sich in den Release Notes. Kunden mit einer gültigen Subskription können Ihr System ab sofort über die bekannten Methoden kostenfrei aktualisieren.

Wie man Analog-ICs am besten auswählt

Antwort: Mein englischer Kollege sagte dazu: „Dies geschieht mit einem gläsernen Schuh. Tragen Sie den Schuh zu allen Herstellern im Land und halten Sie ihn an die Tür. Wenn er im Glas reflektiert wird, können Sie sicher sein, Ihren Herzenswunsch zu finden.“

Spaß beiseite. Einen Baustein über das erforderliche Maß hinaus zu spezifizieren oder ein generell unbekanntes Bausteinmodell zu wählen, kann den Auswahlprozess erschweren und die Kosten von ICs sowie von diskreten Transistoren erhöhen. Deshalb sollten Sie nie schwer zu findende Bauteile oder Angaben unnötiger Parameter verlangen. ICs sind jedoch wesentlich komplexer als Einzeltransistoren. Die Definition aller erforderlichen Parameter erhält damit einen sehr hohen Stellenwert.

In diesem Artikel geht es um allgemeine Grundsätze, nicht um bestimmte IC-Typen wie zum Beispiel Verstärker, Referenzen oder Wandler. Die üblichen Parameter vieler Präzisions-Analog-ICs sind absolute Maximalwerte: ESD-Werte, Versorgungsspannungen, Versorgungsströme, Verlustleistung, Temperaturbereich, Temperaturkoeffizienten, Versorgungsspannungsunterdrückung, Rauschen, Gehäuse, Eingangsimpedanz, Biasstrom, analoges Ausgangsverhalten, und Frequenzbereich. Auch Spezifikationen von Digitalschnittstellen wie Geschwindigkeit, Logiktyp, Logikpegel, Datenkonfiguration und Chip Enable/Shutdown-Funktionen gehören dazu. Bevor man sich mit den Parametern für einen bestimmten Bausteintyp beschäftigt, ist es wichtig zu entscheiden, welche dieser allgemeinen Parameter von Bedeutung sind und in welchen vertretbaren Grenzen sie sich bewegen sollen.

Beginnen sollte man mit einer Liste wichtiger Parameter einschließlich der bausteinspezifischen, um die es später geht. Diese Parameter sollte man ihrer Bedeutung nach ordnen. Als nächstes nutzt man online parametrische Suchmaschinen von mehreren Herstellern und stellt eine Liste mit Bausteinen zusammen, die alle gewünschten Anforderungen erfüllen. Da dies den Besuch mehrerer Webseiten erfordert und Hersteller die Daten in unterschiedlichen Formaten präsentieren, könnte es gut sein, die Webseite eines Distributors zu besuchen. Dort sollten Bauteile verschiedener Hersteller in einem Standardformat dargestellt sein. Leider eignen sich parametrische Vergleiche von Distributoren selten. Sie werden ständig verbessert, doch derzeit ist es im Allgemeinen besser, die Webseiten der Hersteller zu nutzen und Bauteile auf Papier oder in Form einer Tabelle zu vergleichen.

Falls man kein geeignetes Bauteil findet, entscheidet man, welche Parameter nicht zu streng und um wieviel weniger eingehalten werden müssen. Anschließend begibt man sich mit den neuen Werten erneut auf die Suche. Jetzt sollte eine Überprüfung aller Bausteinparameter stattfinden. Dies erfolgt für den Fall, dass ein Leistungsmerkmal einen Baustein besser oder schlechter für die Anwendungen erscheinen lässt.

Zum Schluss listet man alle Bausteine auf, die sich gut eignen, und ermittelt, welcher der preiswerteste ist. Die Kosten für einen IC beinhalten die Bausteinkosten sowie die Kosten für zusätzliche Komponenten oder spezielle Stromversorgungen. Hinzu kommen die Kosten von Anpassungen oder Kalibrierungen, die während der Produktion gemacht werden müssen, sowie die Kosten für die erforderliche Leiterplattenfläche. Wählen Sie bitte das kostengünstigste Bauteil, nicht das billigste.

Der Autor: Von Uwe Bröckelmann nach Unterlagen von Analog Devices