https://kb.pocnet.net/api.php?action=feedcontributions&user=PoC&feedformat=atomKnowledgebase - Benutzerbeiträge [de]2024-03-29T13:04:14ZBenutzerbeiträgeMediaWiki 1.35.11https://kb.pocnet.net/index.php?title=Linux_von_BIOS-_auf_UEFI-Boot_umstellen&diff=3083Linux von BIOS- auf UEFI-Boot umstellen2023-10-18T16:17:25Z<p>PoC: Überarbeitet anhand Deb12</p>
<hr />
<div>Ohne zu wissen, was es mit EFI auf sich hat, ist das '''Umstellen von Linux von BIOS- auf EFI-Boot''' auf echter Serverhardware (die meistens minutenlang in der internen Firmware rumhängt) zeitraubend und frustrierend. In Kürze Erklärung und Wichtiges:<br />
<br />
== Grundlagen ==<br />
(U)EFI ((Unified) Extensible Firmware Interface) ist mit neuerer Hardware unvermeidbar. Eigentlich ist das Thema sehr einfach: Es gibt keinen binären Bootblock mehr, sondern eine kleine FAT32-Partition zu Beginn der Boot-Disk (ggfs. HW-RAID-Array). Die Bootloader der verschiedenen Betriebssysteme erzeugen eine Verzeichnisstruktur, in welcher dann das eigentliche Startprogramm hinterlegt wird. Die Firmware sammelt beim Systemstart eine Liste der gefundenen ausführbaren Binaries (PE32+ executable) und bietet diese dann zum Start an (bzw. der Standardeintrag wird gestartet).<br />
<br />
== Vorbereitungen ==<br />
* Ohne Repartitionieren geht es nicht. Da die Umstellung auf EFI durch einem Hardwaretausch mit anschließender Kopie der vorhandenen Installation durchgeführt wird, ist das aber kein Beinbruch.<br />
* Der initiale Boot (CD, ISO-Image, PXE, USB-Stick, usw.) muss zwingend im EFI-Modus mit einem dementsprechend EFI-fähigen Bootmedium durchgeführt werden. Das Debian-Live-Image von Debian 8 oder älter ist nicht geeignet! Erst ab 9 gibt es EFI-Support, z.&thinsp;B. [https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-12.2.0-amd64-standard.iso debian-live-12.2.0-amd64-standard.iso]. Ohne Boot im EFI-Modus sind die EFI-Hooks in der Firmware unsichtbar und Grub-EFI wird mit Fehlern um sich werfen.<br />
<br />
== Checkliste ==<br />
* Neues System vorbereiten (FW-Updates, BIOS-Settings, usw.),<br />
* Bootmedium vorbereiten (siehe oben),<br />
* Boot via EFI-Bootmenü von diesem Medium,<br />
* Ggfs. manuelle Netzwerkkonfiguration,<br />
* Nachinstallation von benötigten Systemkomponenten,<br />
apt-get install gdisk mdadm dosfstools dump<br />
* Vorbereiten der Platten für das OS:<br />
** Partitionieren (''gdisk''), dabei (eine) z.&thinsp;B. 5&thinsp;MB große EFI-Partition(en) anlegen, Typ EF00,<ref>Tatsächlich benötigt werden vom Grub-Loader einige 100&thinsp;KBytes.</ref><br />
** Ggfs. Erzeugen der gewünschten Arrays mit ''mdadm'',<br />
** Dateisysteme erzeugen, dabei die EFI-Partition(en) mit einem FAT32-Dateisystem versehen,<br />
mkfs.fat /dev/sda1,<br />
** Mounten des OS-Dateisystems nach z.&thinsp;B. ''/mnt'', <code>cd /mnt</code>,<br />
** Kopieren der Installation vom Quellsystem, wie gehabt mit<br />
ssh ''srcsys'' "dump -0a -b 256 -f - /dev/sda1" |restore -r -b 256 -f -<br />
** Vorbereitungen für ''chroot'': <code>mount -o bind /dev dev/</code>,<br />
* <code>chroot /mnt</code>,<br />
* Nachmounten von Kernel-Pseudo-Dateisystemen: <code>mount -t proc none /proc; mount -t sysfs none /sys; mount -t devpts none /dev/pts</code>,<br />
* Anpassen der ''/etc/fstab'', dabei Eintragen der EFI-Partition(en),<br />
/dev/sda1 /boot/efi vfat defaults 0 0<br />
* Anlegen des EFI-Bootverzeichnisses,<br />
mkdir /boot/efi<br />
* Anpassen der ''/etc/fstab'', dabei Eintragen von ''efivars'':<br />
none /sys/firmware/efi/efivars efivarfs defaults 0 0<br />
* Mounten der EFI-Partition(en),<br />
mount -a<br />
* Nachinstallation von auf dem später laufenden System benötigten Systemkomponenten (mdadm),<br />
* Ggfs. schreiben der RAID-Konfiguration mit <code>/usr/share/mdadm/mkconf > /etc/mdadm/mdadm.conf; update-initramfs -u</code>,<br />
* Austauschen von Grub,<br />
apt-get install grub-efi-amd64 grub-efi-amd64-bin<br />
* Sichern der Grub-Defaults,<br />
cp -a /etc/default/grub /etc/default/grub~<br />
* Löschen von altem Grub-PC-Kram, die Frage nach Löschen vom alten Bootloader bejahen,<br />
dpkg -P grub-pc grub-pc-bin<br />
* Restore der Grub-Defaults,<br />
mv /etc/default/grub~ /etc/default/grub<br />
* Restore von gemeinsamen Grub-Dateien durch Reinstallation,<br />
apt-get install --reinstall grub-efi-amd64 grub-efi-amd64-bin<br />
<br />
Grub-EFI erfordert keine Platte mehr als Parameter beim beim Grub-Install:<br />
grub-install<br />
update-grub<br />
<br />
* Raus aus der chroot: <code>exit</code>,<br />
* Unmounten: <code>umount boot/efi* dev/pts dev proc sys; cd ..; umount mnt</code>.<br />
<br />
Nach einem Reboot muss die Installation dann wieder sauber hochkommen. Weitere Schritte wie Netzwerkkonfigurationsanpassungen an die neue Hardware sind nicht beschrieben.<br />
<br />
=== Mögliche Fehler ===<br />
Aus der Praxis…<br />
<br />
==== Meldung: EFI variables are not supported on this system ====<br />
grub-install: warning: EFI variables are not supported on this system.<br />
<br />
Dieser Fehler kann zum einen bedeuten, dass das System selbst im BIOS-Modus gestartet wurde. Allerdings scheint es ab Debian 11 notwendig zu sein, einen weiteren Mountpoint zu setzen:<br />
<br />
none /sys/firmware/efi/efivars efivarfs defaults 0 0<br />
<br />
Damit funktioniert dann auch ein <code>grub-install</code> fehlerfrei.<br />
<br />
==== Nach Reboot erscheint nur die Grub-Kommandozeile ====<br />
Falls das alte BIOS-Grub-Paket mit <code>--purge</code> gelöscht wurde, hätte '''unbedingt''' danach ein<br />
grub-install<br />
update-grub<br />
abgesetzt werden müssen, da das Purge des BIOS-Paketes auch die Konfiguration und weitere Dateien löscht.<br />
<br />
Lösung: Die Schritte von oben nochmal wiederholen:<br />
* Boot von externem Medium,<br />
* <code>chroot</code>,<br />
* Mounten der benötigten Partitionen,<br />
* Grub-Konfiguration neu schreiben:<br />
grub-install<br />
update-grub<br />
* <code>umount</code>,<br />
* Reboot.<br />
<br />
=== Redundanz ===<br />
Beim Booten kann dann statt einem möglicherweise wechselnden Gerät, eine Boot-Konfiguration aus dem genannten Verzeichnis eines beliebigen Gerätes gestartet werden. Vorbei sind die Tage, in denen in einem Software-RAID die erste Platte ausfällt, die zweite Platte dann an die erste Stelle rückt, der Bootblock ist aber nicht auf die erste Platte konfiguriert, sondern entweder überhaupt nicht<ref>Schlampiger Admin…</ref> oder das BIOS kommt mit der neuen BIOS-ID (0x80 statt 0x81) nicht zurecht und verweigert den Boot.<br />
<br />
EFI hat allerdings eine konzeptionelle Schwachstelle: Die Einfachhheit eine ''/boot''-Partition per Software-RAID zu spiegeln ist nicht vorgesehen. Man kann sich was basteln über ''mdadm'' mit nicht persistentem Superblock (damit keine Daten überschrieben werden), aber das ist letztlich alles Gebastel.<br /><br />
Am Einfachsten ist es, manuell die Verzeichnisstruktur auf die zuvor manuell identisch partitionierten und in ''/boot/efi2'', ''/boot/efi3'', usw. gemounteten FAT32-Partitionen zu kopieren.<br />
<br />
Für Debian muss eine Datei angelegt und als ausführbar markiert werden: ''/etc/grub.d/42_update-hook'':<br />
#!/bin/sh<br />
# Dirty hack: If there are multiple FA32-mountpoints in /boot/efi, sync<br />
# contents manually to provide poor man's redundancy.<br />
if mount -t vfat |awk '{print $3}' |grep -q '^/boot/efi$'; then<br />
cat /dev/null > /var/log/update-grub.log<br />
for MP in `mount -t vfat |awk '{print $3}' |grep -v '^/boot/efi$'`; do<br />
rsync -av --delete /boot/efi/ ${MP}/ >> /var/log/update-grub.log<br />
done<br />
else<br />
echo "No EFI Mount Point detected." > /var/log/update-grub.log<br />
fi<br />
<br />
# --EOF--<br />
<br />
Bei jedem Aufruf, der die Grub-Konfiguration neu erzeugt, wird somit auch die Struktur kopiert. Das beinhaltet auch Updates von Kernel und Grub selbst. Fire and forget.<br />
<br />
== Weblinks ==<br />
* [https://outflux.net/blog/archives/2018/04/19/uefi-booting-and-raid1/ UEFI booting and RAID1]<br />
* [https://www.heise.de/newsticker/meldung/Was-Linux-Anwender-ueber-UEFI-wissen-muessen-4204725.html Was Linux-Anwender über UEFI wissen müssen]<br />
* [https://packages.debian.org/stable/bootcd Run your system from cd without need for disks]<ref>Ob das EFI kompatible Images herstellt, ist derzeit nicht bekannt.</ref><br />
* [https://wiki.debian.org/EFIStub …it is possible to load the kernel directly, without any additional bootloader]<br />
<br />
== Fußnoten ==<br />
<references /><br />
<br />
[[Kategorie: Linux]]</div>PoChttps://kb.pocnet.net/index.php?title=Linux_von_BIOS-_auf_UEFI-Boot_umstellen&diff=3082Linux von BIOS- auf UEFI-Boot umstellen2023-10-18T16:02:55Z<p>PoC: /* Fallstricke */ Neueres Image</p>
<hr />
<div>Ohne zu wissen, was es mit EFI auf sich hat, ist das '''Umstellen von Linux von BIOS- auf EFI-Boot''' auf echter Serverhardware (die meistens minutenlang in der internen Firmware rumhängt) zeitraubend und frustrierend. In Kürze Erklärung und Wichtiges:<br />
<br />
== Grundlagen ==<br />
(U)EFI ((Unified) Extensible Firmware Interface) ist mit neuerer Hardware unvermeidbar. Eigentlich ist das Thema sehr einfach: Es gibt keinen binären Bootblock mehr, sondern eine kleine FAT32-Partition zu Beginn der Boot-Disk (ggfs. HW-RAID-Array). Die Bootloader der verschiedenen Betriebssysteme erzeugen eine Verzeichnisstruktur, in welcher dann das eigentliche Startprogramm hinterlegt wird. Die Firmware sammelt beim Systemstart eine Liste der gefundenen ausführbaren Binaries (PE32+ executable) und bietet diese dann zum Start an (bzw. der Standardeintrag wird gestartet).<br />
<br />
== Fallstricke ==<br />
* Ohne Repartitionieren geht es nicht. Da die Umstellung auf EFI durch einem Hardwaretausch mit anschließender Kopie der vorhandenen Installation durchgeführt wird, ist das aber kein Beinbruch.<br />
* Der initiale Boot (CD, ISO-Image, PXE, USB-Stick, usw.) muss zwingend im EFI-Modus mit einem dementsprechend EFI-fähigen Bootmedium durchgeführt werden. Das Debian-Live-Image von Debian 8 oder älter ist nicht geeignet! Erst ab 9 gibt es EFI-Support, z.&thinsp;B. [https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-12.2.0-amd64-standard.iso debian-live-12.2.0-amd64-standard.iso]. Ohne Boot im EFI-Modus sind die EFI-Hooks in der Firmware unsichtbar und Grub-EFI wird mit Fehlern um sich werfen.<br />
* Falls das alte BIOS-Grub-Paket mit <code>--purge</code> gelöscht wird, ist '''unbedingt''' danach ein<br />
grub-install dummy<br />
update-grub<br />
abzusetzen, da das Purge des BIOS-Paketes auch die Konfiguration und weitere Dateien löscht. Nach einem Reboot gibt's ansonsten die Grub-Kommandozeile.<br />
<br />
== Checkliste ==<br />
* Neues System vorbereiten (FW-Updates, BIOS-Settings, usw.),<br />
* Bootmedium vorbereiten (siehe oben),<br />
* Boot via EFI-Bootmenü von diesem Medium,<br />
* Ggfs. manuelle Netzwerkkonfiguration,<br />
* Nachinstallation von benötigten Systemkomponenten (gdisk, mdadm, dosfstools),<br />
* Vorbereiten der Platten für das OS:<br />
** Partitionieren (''gdisk''), dabei (eine) z.&thinsp;B. 5&thinsp;MB große EFI-Partition(en) anlegen, Typ EF00,<ref>Tatsächlich benötigt werden vom Grub-Loader einige 100&thinsp;KBytes.</ref><br />
** Ggfs. Erzeugen der gewünschten Arrays mit ''mdadm'',<br />
** Dateisysteme erzeugen, dabei die EFI-Partition(en) mit einem FAT32-Dateisystem versehen, z.&thinsp;B.: <code>mkfs.fat -F32 /dev/sda1</code>,<br />
** Mounten des OS-Dateisystems nach z.&thinsp;B. ''/mnt'', <code>cd /mnt</code>,<br />
** Kopieren der Installation vom Quellsystem, wie gehabt mit z.&thinsp;B. <code>ssh ''srcsys'' "dump -0a -b 256 -f - /dev/sda1" |restore -r -b 256 -f -</code>,<br />
** Vorbereitungen für ''chroot'': <code>mount -o bind /dev dev/</code>,<br />
* <code>chroot /mnt</code>,<br />
* Nachmounten von Kernel-Pseudo-Dateisystemen: <code>mount -t proc none /proc; mount -t sysfs none /sys; mount -t devpts none /dev/pts</code>,<br />
* Anpassen der ''/etc/fstab'', dabei Eintragen der EFI-Partition(en),<br />
* Anpassen der ''/etc/fstab'', dabei Eintragen von ''efivars'':<br />
none /sys/firmware/efi/efivars efivarfs defaults 0 0<br />
* Mounten der EFI-Partition(en),<br />
* Nachinstallation von benötigten Systemkomponenten (gdisk, mdadm, dosfstools),<br />
* Ggfs. schreiben der RAID-Konfiguration mit <code>/usr/share/mdadm/mkconf > /etc/mdadm/mdadm.conf; update-initramfs -u</code>,<br />
* Austauschen von Grub: <code>apt-get install grub-efi-amd64 grub-efi-amd64-bin</code>,<br />
* Löschen von altem Grub-PC-Kram: <code>dpkg -P grub-pc grub-pc-bin</code>,<br />
* Prüfen, ob ''/etc/default/grub'' existiert und falls nicht, nochmal vom Backup kopieren.<br />
<br />
Grub-EFI erfordert keine Platte mehr als Parameter beim beim Grub-Install. Statt dessen wird als (leider benötigter Parameter) ''dummy'' übergeben.<br />
grub-install dummy<br />
<br />
* Raus aus der chroot: <code>exit</code>,<br />
* Unmounten: <code>umount boot/efi* dev proc sys; cd ..; umount mnt</code>.<br />
<br />
Nach einem Reboot muss die Installation dann wieder sauber hochkommen. Weitere Schritte wie Netzwerkkonfigurationsanpassungen an die neue Hardware sind nicht beschrieben.<br />
<br />
=== Mögliche Fehler ===<br />
grub-install: warning: EFI variables are not supported on this system.<br />
<br />
Dieser Fehler kann zum einen bedeuten, dass das System selbst im BIOS-Modus gestartet wurde. Allerdings scheint es ab Debian 11 notwendig zu sein, einen weiteren Mountpoint zu setzen:<br />
<br />
none /sys/firmware/efi/efivars efivarfs defaults 0 0<br />
<br />
Damit funktioniert dann auch ein <code>grub-install</code> fehlerfrei.<br />
<br />
=== Redundanz ===<br />
Beim Booten kann dann statt einem möglicherweise wechselnden Gerät, eine Boot-Konfiguration aus dem genannten Verzeichnis eines beliebigen Gerätes gestartet werden. Vorbei sind die Tage, in denen in einem Software-RAID die erste Platte ausfällt, die zweite Platte dann an die erste Stelle rückt, der Bootblock ist aber nicht auf die erste Platte konfiguriert, sondern entweder überhaupt nicht<ref>Schlampiger Admin…</ref> oder das BIOS kommt mit der neuen BIOS-ID (0x80 statt 0x81) nicht zurecht und verweigert den Boot.<br />
<br />
EFI hat allerdings eine konzeptionelle Schwachstelle: Die Einfachhheit eine ''/boot''-Partition per Software-RAID zu spiegeln ist nicht vorgesehen. Man kann sich was basteln über ''mdadm'' mit nicht persistentem Superblock (damit keine Daten überschrieben werden), aber das ist letztlich alles Gebastel.<br /><br />
Am Einfachsten ist es, manuell die Verzeichnisstruktur auf die zuvor manuell identisch partitionierten und in ''/boot/efi2'', ''/boot/efi3'', usw. gemounteten FAT32-Partitionen zu kopieren.<br />
<br />
Für Debian muss eine Datei angelegt und als ausführbar markiert werden: ''/etc/grub.d/42_update-hook'':<br />
#!/bin/sh<br />
# Dirty hack: If there are multiple FA32-mountpoints in /boot/efi, sync<br />
# contents manually to provide poor man's redundancy.<br />
if mount -t vfat |awk '{print $3}' |grep -q '^/boot/efi$'; then<br />
cat /dev/null > /var/log/update-grub.log<br />
for MP in `mount -t vfat |awk '{print $3}' |grep -v '^/boot/efi$'`; do<br />
rsync -av --delete /boot/efi/ ${MP}/ >> /var/log/update-grub.log<br />
done<br />
else<br />
echo "No EFI Mount Point detected." > /var/log/update-grub.log<br />
fi<br />
<br />
# --EOF--<br />
<br />
Bei jedem Aufruf, der die Grub-Konfiguration neu erzeugt, wird somit auch die Struktur kopiert. Das beinhaltet auch Updates von Kernel und Grub selbst. Fire and forget.<br />
<br />
== Weblinks ==<br />
* [https://outflux.net/blog/archives/2018/04/19/uefi-booting-and-raid1/ UEFI booting and RAID1]<br />
* [https://www.heise.de/newsticker/meldung/Was-Linux-Anwender-ueber-UEFI-wissen-muessen-4204725.html Was Linux-Anwender über UEFI wissen müssen]<br />
* [https://packages.debian.org/stable/bootcd Run your system from cd without need for disks]<ref>Ob das EFI kompatible Images herstellt, ist derzeit nicht bekannt.</ref><br />
* [https://wiki.debian.org/EFIStub …it is possible to load the kernel directly, without any additional bootloader]<br />
<br />
== Fußnoten ==<br />
<references /><br />
<br />
[[Kategorie: Linux]]</div>PoChttps://kb.pocnet.net/index.php?title=Systemd_bei_Debian_loswerden&diff=3081Systemd bei Debian loswerden2023-10-18T12:14:39Z<p>PoC: Test mit Deb 11: Kein shim mehr, Rest funktioniert 1:1</p>
<hr />
<div>'''Debian Jessie''' (8) (und neuer) bringt per Default ein neues Startsystem, mit: Systemd. Nach sorgfältiger Recherche und Abwägen des Für und Wider habe ich mich dazu entschlossen, meine Debian-Installationen ohne '''Systemd''' zu betreiben, sondern auf die nach wie vor unterstützte traditionelle Sysv-Umgebung zu setzen. Bei den Betrachtungen ist wichtig, dass es hier nicht um Desktopsysteme geht, sondern um Serverinstallationen.<br />
<br />
Diese Anleitung wurde mit Debian Buster (10) verifiziert.<br />
<br />
Mit Debian 12 (Bookworm) gibt es wohl neue Paketabhängigkeiten, weswegen diese Anleitung nicht mehr funktioniert.<br />
<br />
== Gründe ==<br />
Achtung, dies ist meine subjektive Betrachtungsweise!<br />
<br />
* Systemd ist unübersichtlich, weil Systemd alles abdecken möchte, was derzeit von bekannten und gut funktionierenden Subsystemen abgedeckt wird:<br />
** ''Init'' für Runlevelmanagement und Startvorgang,<br />
** ''Udev'' für dynamische ''/dev''-Nodes und Netzwerkinterfaces,<br />
** Ergänzung/Ablöse von ''(x)inetd'' zwecks Nachstarten von Prozessen,<br />
** evtl. weiteres, was mir bisher nicht negativ aufgefallen ist.<br />
<br />
Welche eigentlich netten und relevanten Features verlieren die Installationen durch den Verzicht?<br />
* Den beeindruckend schnellen Startvorgang, u.&thinsp;A. durch Parallelisierung von Daemonstarts,<br />
* Automatische Prozessisolation durch die Integration von ''cgroups'' in den Startvorgang.<br />
<br />
Was gewinnt man durch den Verzicht?<br />
* Eine bekannte, verlässliche und durch jahrelange Erfahrung gestützte Systemumgebung, die alte Hasen im Schlaf und zeitgleichem Vollsuff beherrschen; ein nicht zu unterschätzender Punkt für Serveradministratoren,<br />
* deutlich näher dran an ''[https://en.wikipedia.org/wiki/Everything_is_a_file everything is a file]'',<br />
* erprobtes Logging im ASCII-Format mit allen Vorteilen wie z.&thinsp;B. ''grep''.<br />
<br />
== Vorgehensweise ==<br />
apt-get install sysvinit-core bootlogd systemd-sysv-<br />
reboot<br />
<br />
Danach:<br />
apt-get autoremove --purge systemd<br />
<br />
Fertig.<br />
<br />
Beim letzten ''apt-get''-Aufruf sollte geprüft werden, ob eventuell weitere Pakete deinstalliert werden, welche ''Systemd'' als Abhängigkeit besitzen. Bei Serverinstallationen dürfte dies in der Regel nicht der Fall sein.<br />
<br />
== Siehe auch ==<br />
* [[Debian-Upgrade auf Jessie ohne Systemd]]<br />
<br />
== Weblinks ==<br />
* [http://www.freedesktop.org/wiki/Software/systemd/ Systemd Projektseite] (en)<br />
* [http://unix.stackexchange.com/questions/5877/what-are-the-pros-cons-of-upstart-and-systemd Darlegung von Für/Wider] bei Stackexchange (en)<br />
* [http://0pointer.de/blog/projects/the-biggest-myths.html Mythen über Systemd] (en)<br />
* [http://www.simonrichter.eu/blog/2016-03-03-why-sysvinit.html SimonRichter/ blog/ Why sysvinit?] (en)<br />
* [https://unix.stackexchange.com/questions/218933/after-switching-to-devuan-how-do-i-remove-systemd After switching to Devuan, how do I remove systemd?] (en)<br />
<br />
[[Kategorie:Linux]]</div>PoChttps://kb.pocnet.net/index.php?title=Linux_von_BIOS-_auf_UEFI-Boot_umstellen&diff=3080Linux von BIOS- auf UEFI-Boot umstellen2023-10-18T12:13:43Z<p>PoC: /* Checkliste */ 5MB reichen</p>
<hr />
<div>Ohne zu wissen, was es mit EFI auf sich hat, ist das '''Umstellen von Linux von BIOS- auf EFI-Boot''' auf echter Serverhardware (die meistens minutenlang in der internen Firmware rumhängt) zeitraubend und frustrierend. In Kürze Erklärung und Wichtiges:<br />
<br />
== Grundlagen ==<br />
(U)EFI ((Unified) Extensible Firmware Interface) ist mit neuerer Hardware unvermeidbar. Eigentlich ist das Thema sehr einfach: Es gibt keinen binären Bootblock mehr, sondern eine kleine FAT32-Partition zu Beginn der Boot-Disk (ggfs. HW-RAID-Array). Die Bootloader der verschiedenen Betriebssysteme erzeugen eine Verzeichnisstruktur, in welcher dann das eigentliche Startprogramm hinterlegt wird. Die Firmware sammelt beim Systemstart eine Liste der gefundenen ausführbaren Binaries (PE32+ executable) und bietet diese dann zum Start an (bzw. der Standardeintrag wird gestartet).<br />
<br />
== Fallstricke ==<br />
* Ohne Repartitionieren geht es nicht. Da die Umstellung auf EFI durch einem Hardwaretausch mit anschließender Kopie der vorhandenen Installation durchgeführt wird, ist das aber kein Beinbruch.<br />
* Der initiale Boot (CD, ISO-Image, PXE, USB-Stick, usw.) muss zwingend im EFI-Modus mit einem dementsprechend EFI-fähigen Bootmedium durchgeführt werden. Das Debian-Live-Image von Debian 8 oder älter ist nicht geeignet! Erst ab 9 gibt es EFI-Support, z.&thinsp;B. [http://cdimage.debian.org/debian-cd/9.6.0-live/amd64/iso-hybrid/debian-live-9.6.0-amd64-xfce.iso debian-live-9.6.0-amd64-xfce.iso]. Ohne Boot im EFI-Modus sind die EFI-Hooks in der Firmware unsichtbar und Grub-EFI wird mit Fehlern um sich werfen.<br />
* Falls das alte BIOS-Grub-Paket mit <code>--purge</code> gelöscht wird, ist '''unbedingt''' danach ein<br />
grub-install dummy<br />
update-grub<br />
abzusetzen, da das Purge des BIOS-Paketes auch die Konfiguration und weitere Dateien löscht. Nach einem Reboot gibt's ansonsten die Grub-Kommandozeile.<br />
<br />
== Checkliste ==<br />
* Neues System vorbereiten (FW-Updates, BIOS-Settings, usw.),<br />
* Bootmedium vorbereiten (siehe oben),<br />
* Boot via EFI-Bootmenü von diesem Medium,<br />
* Ggfs. manuelle Netzwerkkonfiguration,<br />
* Nachinstallation von benötigten Systemkomponenten (gdisk, mdadm, dosfstools),<br />
* Vorbereiten der Platten für das OS:<br />
** Partitionieren (''gdisk''), dabei (eine) z.&thinsp;B. 5&thinsp;MB große EFI-Partition(en) anlegen, Typ EF00,<ref>Tatsächlich benötigt werden vom Grub-Loader einige 100&thinsp;KBytes.</ref><br />
** Ggfs. Erzeugen der gewünschten Arrays mit ''mdadm'',<br />
** Dateisysteme erzeugen, dabei die EFI-Partition(en) mit einem FAT32-Dateisystem versehen, z.&thinsp;B.: <code>mkfs.fat -F32 /dev/sda1</code>,<br />
** Mounten des OS-Dateisystems nach z.&thinsp;B. ''/mnt'', <code>cd /mnt</code>,<br />
** Kopieren der Installation vom Quellsystem, wie gehabt mit z.&thinsp;B. <code>ssh ''srcsys'' "dump -0a -b 256 -f - /dev/sda1" |restore -r -b 256 -f -</code>,<br />
** Vorbereitungen für ''chroot'': <code>mount -o bind /dev dev/</code>,<br />
* <code>chroot /mnt</code>,<br />
* Nachmounten von Kernel-Pseudo-Dateisystemen: <code>mount -t proc none /proc; mount -t sysfs none /sys; mount -t devpts none /dev/pts</code>,<br />
* Anpassen der ''/etc/fstab'', dabei Eintragen der EFI-Partition(en),<br />
* Anpassen der ''/etc/fstab'', dabei Eintragen von ''efivars'':<br />
none /sys/firmware/efi/efivars efivarfs defaults 0 0<br />
* Mounten der EFI-Partition(en),<br />
* Nachinstallation von benötigten Systemkomponenten (gdisk, mdadm, dosfstools),<br />
* Ggfs. schreiben der RAID-Konfiguration mit <code>/usr/share/mdadm/mkconf > /etc/mdadm/mdadm.conf; update-initramfs -u</code>,<br />
* Austauschen von Grub: <code>apt-get install grub-efi-amd64 grub-efi-amd64-bin</code>,<br />
* Löschen von altem Grub-PC-Kram: <code>dpkg -P grub-pc grub-pc-bin</code>,<br />
* Prüfen, ob ''/etc/default/grub'' existiert und falls nicht, nochmal vom Backup kopieren.<br />
<br />
Grub-EFI erfordert keine Platte mehr als Parameter beim beim Grub-Install. Statt dessen wird als (leider benötigter Parameter) ''dummy'' übergeben.<br />
grub-install dummy<br />
<br />
* Raus aus der chroot: <code>exit</code>,<br />
* Unmounten: <code>umount boot/efi* dev proc sys; cd ..; umount mnt</code>.<br />
<br />
Nach einem Reboot muss die Installation dann wieder sauber hochkommen. Weitere Schritte wie Netzwerkkonfigurationsanpassungen an die neue Hardware sind nicht beschrieben.<br />
<br />
=== Mögliche Fehler ===<br />
grub-install: warning: EFI variables are not supported on this system.<br />
<br />
Dieser Fehler kann zum einen bedeuten, dass das System selbst im BIOS-Modus gestartet wurde. Allerdings scheint es ab Debian 11 notwendig zu sein, einen weiteren Mountpoint zu setzen:<br />
<br />
none /sys/firmware/efi/efivars efivarfs defaults 0 0<br />
<br />
Damit funktioniert dann auch ein <code>grub-install</code> fehlerfrei.<br />
<br />
=== Redundanz ===<br />
Beim Booten kann dann statt einem möglicherweise wechselnden Gerät, eine Boot-Konfiguration aus dem genannten Verzeichnis eines beliebigen Gerätes gestartet werden. Vorbei sind die Tage, in denen in einem Software-RAID die erste Platte ausfällt, die zweite Platte dann an die erste Stelle rückt, der Bootblock ist aber nicht auf die erste Platte konfiguriert, sondern entweder überhaupt nicht<ref>Schlampiger Admin…</ref> oder das BIOS kommt mit der neuen BIOS-ID (0x80 statt 0x81) nicht zurecht und verweigert den Boot.<br />
<br />
EFI hat allerdings eine konzeptionelle Schwachstelle: Die Einfachhheit eine ''/boot''-Partition per Software-RAID zu spiegeln ist nicht vorgesehen. Man kann sich was basteln über ''mdadm'' mit nicht persistentem Superblock (damit keine Daten überschrieben werden), aber das ist letztlich alles Gebastel.<br /><br />
Am Einfachsten ist es, manuell die Verzeichnisstruktur auf die zuvor manuell identisch partitionierten und in ''/boot/efi2'', ''/boot/efi3'', usw. gemounteten FAT32-Partitionen zu kopieren.<br />
<br />
Für Debian muss eine Datei angelegt und als ausführbar markiert werden: ''/etc/grub.d/42_update-hook'':<br />
#!/bin/sh<br />
# Dirty hack: If there are multiple FA32-mountpoints in /boot/efi, sync<br />
# contents manually to provide poor man's redundancy.<br />
if mount -t vfat |awk '{print $3}' |grep -q '^/boot/efi$'; then<br />
cat /dev/null > /var/log/update-grub.log<br />
for MP in `mount -t vfat |awk '{print $3}' |grep -v '^/boot/efi$'`; do<br />
rsync -av --delete /boot/efi/ ${MP}/ >> /var/log/update-grub.log<br />
done<br />
else<br />
echo "No EFI Mount Point detected." > /var/log/update-grub.log<br />
fi<br />
<br />
# --EOF--<br />
<br />
Bei jedem Aufruf, der die Grub-Konfiguration neu erzeugt, wird somit auch die Struktur kopiert. Das beinhaltet auch Updates von Kernel und Grub selbst. Fire and forget.<br />
<br />
== Weblinks ==<br />
* [https://outflux.net/blog/archives/2018/04/19/uefi-booting-and-raid1/ UEFI booting and RAID1]<br />
* [https://www.heise.de/newsticker/meldung/Was-Linux-Anwender-ueber-UEFI-wissen-muessen-4204725.html Was Linux-Anwender über UEFI wissen müssen]<br />
* [https://packages.debian.org/stable/bootcd Run your system from cd without need for disks]<ref>Ob das EFI kompatible Images herstellt, ist derzeit nicht bekannt.</ref><br />
* [https://wiki.debian.org/EFIStub …it is possible to load the kernel directly, without any additional bootloader]<br />
<br />
== Fußnoten ==<br />
<references /><br />
<br />
[[Kategorie: Linux]]</div>PoChttps://kb.pocnet.net/index.php?title=BBEdit_Einstellungen_auf_Standard_nach_Update&diff=3054BBEdit Einstellungen auf Standard nach Update2023-09-04T08:41:12Z<p>PoC: reworked</p>
<hr />
<div>Seitdem ''TextWrangler'' nicht mehr weiterentwickelt wird und stattdessen eine Light-Version von ''BBEdit'' dessen Funktion übernehmen soll, kommt es immer wieder vor, dass nach einem Upgrade via Appstore die '''Einstellungen von BBEdit wieder zurück auf Standard gesetzt werden'''. Ob dies einem Schluckauf der OS X Sandbox geschuldet ist, oder andere Ursachen hat, lässt sich nicht ohne weiteres feststellen.<br />
<br />
Jedenfalls ist es ärgerlich, wenn die über längere Zeit etablierten Einstellungen plötzlich weg sind.<br />
<br />
== Lokation ==<br />
Die Einstelllungen selbst befinden sich in ''~/Library/Containers/com.barebones.bbedit/Data/Library/Preferences/com.barebones.bbedit.plist''. Diese Datei kann man sich recht einfach aus einem Timemachine-Backup zurückholen. Dummerweise sieht die Verzeichnisstruktur im Finder leicht anders aus. Dort ist es ''~/Library/Containers/BBEdit/Data/Library/Preferences/com.barebones.bbedit.plist''.<br />
<br />
<s>Am Besten man öffnet sich via Terminal-Kommando den standardmäßig versteckten ''Library''-Ordner und hangelt sich via Finder-Fenster durch:<br />
open ~/Library<br />
<br />
Danach markiert man die Prefs-Datei, wählt im Time Machine Menü ''Time Machine öffnen'' und sucht sich einen hinreichend alten Stand raus, definitiv vor dem letzten Upgrade.</s><br />
<br />
Mit der Shell hangelt man sich dann durch das Time Machine Backup Volume (unterhalb ''/Volumes/'') und bis zum o.&thinsp;G. Ordner durch. Mittels <code>cp com.barebones.bbedit.plist ~/Library/Containers/com.barebones.bbedit/Data/Library/Preferences/</code> kopiert man den alten Stand.<br />
<br />
Damit ist das Problem (temporär, bis zu wieder einem anderen Upgrade) gelöst.<br />
<br />
[[Kategorie: Datensicherung]]<br />
[[Kategorie: Mac OS X]]</div>PoChttps://kb.pocnet.net/index.php?title=Systemd_bei_Debian_loswerden&diff=3053Systemd bei Debian loswerden2023-06-24T14:12:08Z<p>PoC: Versionstests, toten Link entfernt</p>
<hr />
<div>'''Debian Jessie''' (8) (und neuer) bringt per Default ein neues Startsystem, mit: Systemd. Nach sorgfältiger Recherche und Abwägen des Für und Wider habe ich mich dazu entschlossen, meine Debian-Installationen ohne '''Systemd''' zu betreiben, sondern auf die nach wie vor unterstützte traditionelle Sysv-Umgebung zu setzen. Bei den Betrachtungen ist wichtig, dass es hier nicht um Desktopsysteme geht, sondern um Serverinstallationen.<br />
<br />
Diese Anleitung wurde mit Debian Buster (10) verifiziert.<br />
<br />
Mit Debian 12 (Bookworm) gibt es wohl neue Paketabhängigkeiten, weswegen diese Anleitung nicht mehr funktioniert.<br />
<br />
== Gründe ==<br />
Achtung, dies ist meine subjektive Betrachtungsweise!<br />
<br />
* Systemd ist unübersichtlich, weil Systemd alles abdecken möchte, was derzeit von bekannten und gut funktionierenden Subsystemen abgedeckt wird:<br />
** ''Init'' für Runlevelmanagement und Startvorgang,<br />
** ''Udev'' für dynamische ''/dev''-Nodes und Netzwerkinterfaces,<br />
** Ergänzung/Ablöse von ''(x)inetd'' zwecks Nachstarten von Prozessen,<br />
** evtl. weiteres, was mir bisher nicht negativ aufgefallen ist.<br />
<br />
Welche eigentlich netten und relevanten Features verlieren die Installationen durch den Verzicht?<br />
* Den beeindruckend schnellen Startvorgang, u.&thinsp;A. durch Parallelisierung von Daemonstarts,<br />
* Automatische Prozessisolation durch die Integration von ''cgroups'' in den Startvorgang.<br />
<br />
Was gewinnt man durch den Verzicht?<br />
* Eine bekannte, verlässliche und durch jahrelange Erfahrung gestützte Systemumgebung, die alte Hasen im Schlaf und zeitgleichem Vollsuff beherrschen; ein nicht zu unterschätzender Punkt für Serveradministratoren,<br />
* deutlich näher dran an ''[https://en.wikipedia.org/wiki/Everything_is_a_file everything is a file]'',<br />
* erprobtes Logging im ASCII-Format mit allen Vorteilen wie z.&thinsp;B. ''grep''.<br />
<br />
== Vorgehensweise ==<br />
apt-get install sysvinit-core systemd-shim bootlogd systemd-sysv-<br />
reboot<br />
<br />
Danach:<br />
apt-get autoremove --purge systemd systemd-shim<br />
<br />
Fertig.<br />
<br />
Beim letzten ''apt-get''-Aufruf sollte geprüft werden, ob eventuell weitere Pakete deinstalliert werden, welche ''Systemd'' als Abhängigkeit besitzen. Bei Serverinstallationen dürfte dies in der Regel nicht der Fall sein.<br />
<br />
== Siehe auch ==<br />
* [[Debian-Upgrade auf Jessie ohne Systemd]]<br />
<br />
== Weblinks ==<br />
* [http://www.freedesktop.org/wiki/Software/systemd/ Systemd Projektseite] (en)<br />
* [http://unix.stackexchange.com/questions/5877/what-are-the-pros-cons-of-upstart-and-systemd Darlegung von Für/Wider] bei Stackexchange (en)<br />
* [http://0pointer.de/blog/projects/the-biggest-myths.html Mythen über Systemd] (en)<br />
* [http://www.simonrichter.eu/blog/2016-03-03-why-sysvinit.html SimonRichter/ blog/ Why sysvinit?] (en)<br />
* [https://unix.stackexchange.com/questions/218933/after-switching-to-devuan-how-do-i-remove-systemd After switching to Devuan, how do I remove systemd?] (en)<br />
<br />
[[Kategorie:Linux]]</div>PoChttps://kb.pocnet.net/index.php?title=Apple_TimeMachine_Backup_in_Disk_Image&diff=2999Apple TimeMachine Backup in Disk Image2023-05-07T14:12:22Z<p>PoC: /* Siehe auch */ +Link</p>
<hr />
<div>'''Apple TimeMachine''' ist ziemlich wählerisch, wohin es Backups macht. Ursprünglich sollte das eine lokal angehängte Disk sein, mit der man im Katastrophenfall starten und dann direkt auf das neue Speichermedium rücksichern kann.<br />
<br />
Seit längerer Zeit beherrschen Macs das Starten via Internet bzw. den dort angeschlossenen Apple Servern — sofern man eine funktionierende Internetverbindung hat eine praktische Sache. Damit ist das Thema Starten für Restore vakant.<br />
<br />
== Notwendige Schritte ==<br />
Im Terminal:<br />
* '''Lokales''' Backupimage anlegen. Angelegt wird das im aktuellen Verzeichnis. Im Regelfall ist das das Homeverzeichnis. Die Parameter sollten nach Notwendigkeit angepasst werden.<br />
hdiutil create -size 500G -fs HFS+J -volname 'Backup Volume' Backupvolume.sparsebundle<br />
<br />
* Mounten des Servervolumes (mit ''Cmd-K'') und Kopieren des Images via Finder.<blockquote>'''Achtung!''' Anlegen des Images direkt auf dem Server dauert erheblich länger und legt kein Sparsebundle an, sondern die Datei in voller Größe!</blockquote>Nach dem Kopieren kann die lokale Version gelöscht werden.<br />
<br />
* Image auf dem Server doppelklicken (mounten).<br />
<br />
* Timemachine via Kommandozeile im Terminal anweisen, das gemountete Volume zu benutzen. ''Sudo'' wird nach dem Passwort fragen!<br />
sudo tmutil setdestination /Volumes/'Backup Volume'<br />
<br />
In den TimeMachine Systemeinstellungen bzw. über die Menüleiste kann nun das erste Backup von Hand gestartet werden.<br />
<br />
== Siehe auch ==<br />
* [https://foliovision.com/2010/05/network-backup-apple-timemachine How to create a network backup with Apple’s TimeMachine], FolioVision<br />
* [https://www.makeuseof.com/tag/turn-nas-windows-share-time-machine-backup/ Turn Your NAS Or Windows Share Into A Time Machine Backup], Makeuseof.com<br />
<br />
[[Kategorie: Datensicherung]]<br />
[[Kategorie: Mac OS X]]</div>PoChttps://kb.pocnet.net/index.php?title=AS/400_DNS-Server_ohne_OpNav&diff=2935AS/400 DNS-Server ohne OpNav2023-01-23T15:52:10Z<p>PoC: Typo</p>
<hr />
<div>Der '''DNS-Server''' von OS/400 kann offiziell nur via '''OpNav''' konfiguriert werden. Es geht aber auch anders…<br />
<br />
OpNav ist ein Bestandteil von ClientAccess für Windows, was bei einer OS/400-Installation mit installiert wird. Bei alten OS/400-Versionen wird eine entsprechend alte ClientAccess-Version mitgeliefert, die unter aktuellen Windows-Versionen nicht oder nicht mehr sauber läuft. Erschwerend kommt hinzu, dass der SMB-Server dieser alten Versionen nicht mehr mit dem neueren Client-Code in neueren Windows-Versionen harmoniert — Zugriff leider nicht möglich. Somit bleibt nur FTP zum Datenaustausch.<br />
<br />
== Konfiguration ==<br />
Dns DNS von OS/400 V4R2 bis einschliesslich V4R5 basiert auf BIND 4.9.3 vom ISC. Somit gelten auch die Konfigurationsdirektiven unmittelbar. Beim Start wird nach der Hauptkonfiguratiosndatei ''/QIBM/USERDATA/OS400/DNS/BOOT'' gesucht. Diese kann man bequem selbst erstellen:<br />
<br />
EDTF '/QIBM/USERDATA/OS400/DNS/BOOT'<br />
<br />
Beispiel:<br />
; Working Directory<br />
directory /QIBM/USERDATA/OS400/DNS<br />
; Root-DNS-File<br />
cache . NAMED.ROOT<br />
; Zone Statements<br />
secondary myzone.com 192.168.1.11 db.myzone.com<br />
<br />
''EDTF'' ist in der Bedienung sehr ähnlich zu ''SEU''. Alternativ kann man diese Datei auch woanders erstellen und im ASCII-Mode per FTP an die passende Stelle laden.<br />
<br />
Es empfiehlt sich, eine aktuelle Rootzonen-Datei zu importieren. Diese erhält man z.&thinsp;B. bei [https://www.internic.net/domain/named.root Internic] und kann per FTP nach ''QDNS/QATOCDNSRV.ROOT'' als auch nach — wie in der entsprechenden Direktive angegeben — nach ''/QIBM/USERDATA/OS400/DNS/ROOT.HINT'' übertragen werden.<ref>Der BIND kann mit einer Datei in einer Library nichts anfangen.</ref><br />
<br />
Vor dem Start des DNS-Servers sollten die Verzeichnisrechte angepasst werden:<br />
STRQSH CMD('CHOWN QTCP /QIBM/USERDATA/OS400/DNS')<br />
<br />
Mit <code>CHGDNSA</code> kann der Autostart beim TCP-Start als auch der Debuglevel festgelegt und danach der Server mit <code>STRTCPSVR *DNS</code> gestartet werden.<br />
<br />
Weniger erfreulich ist die Tatsache, dass sich beim Test des DNS als Secondary zu einem BIND 9.10.3 unter Debian Linux keine Sekundärzonen laden lassen. Der Primärserver schiebt die Zonen via AXFR raus, der Slave auf der AS/400 nimmt diese leider nicht an. Gemäß Job Log der AXFRs erwartet BIND mehr Datenbytes als er geliefert bekommt.<br />
<br />
== Weblinks ==<br />
* [http://www.cs.ait.ac.th/~on/O/oreilly/tcpip/dnsbind/ch04_03.htm Setting Up a BIND Configuration File], O'Reilly Books<br />
* [https://www.redbooks.ibm.com/redbooks/pdfs/sg245147.pdf AS/400 TCP/IP Autoconfiguration: DNS and DHCP Support], IBM RedBooks<br />
<br />
[[Kategorie: AS/400]]</div>PoChttps://kb.pocnet.net/index.php?title=Apple_SNA%E2%80%A2ps_Konfiguration_f%C3%BCr_5250-Sitzungen&diff=2934Apple SNA•ps Konfiguration für 5250-Sitzungen2023-01-07T02:31:29Z<p>PoC: mv => try-as400</p>
<hr />
<div>Der Artikel ist in englischer Sprache im [https://try-as400.pocnet.net/wiki/Apple_SNA•ps AS/400-Wiki] abrufbar.<br />
<br />
Die Pflege von Artikeln in zwei Sprachen ist mir zu aufwendig.<br />
<br />
[[Kategorie: AS/400]]<br />
[[Kategorie: Mac OS]]<br />
[[Kategorie: Netzwerk]]</div>PoChttps://kb.pocnet.net/index.php?title=Apple_SNA%E2%80%A2ps_Konfiguration_f%C3%BCr_5250-Sitzungen&diff=2933Apple SNA•ps Konfiguration für 5250-Sitzungen2023-01-06T21:21:07Z<p>PoC: Gliederung</p>
<hr />
<div>[[Datei:5250term.gif|thumb|right|5250 Clientverbindung via SNA•ps]]<br />
[[Datei:Snagw-run.gif|thumb|right|SNA•ps Gateway Fenster]]<br />
'''Apple SNA•ps''' ist eine Software, welche die Kommunikation von Apple Macs mit System 7.x mit IBM-Rechnersystemen ermöglicht. Die Kommunikation mit den Rechnern findet hierbei nicht wie heutzutage üblich über IP statt, sondern über Protokolle im Rahmen von '''SNA''' (Systems Network Architecture).<ref>Neuere Versionen vom SNA•ps 5250 Client unterstützen auch IP/tn5250 als Transportweg.</ref><br /><br />
Das Programmpaket wurde als Ergebnis einer erklärten Zusammenarbeit von IBM und Apple Anfang der 1990er Jahre von Orion Software programmiert.<br />
<br />
SNA•ps gibt es zum einen als Gateway mit einer lizenzabhängigen Maximalanzahl von 8, 32 oder 64 [https://en.wikipedia.org/wiki/IBM_Systems_Network_Architecture#Logical_Unit_.28LU.29 LU]-Sessions, zum anderen als Client für 5250-Terminal- und Druckservices als auch 3270-Terminalservices. Dieser Artikel konzentriert sich auf das Thema AS/400 bzw. 5250-Anbindung.<br />
<br />
== Funktionsüberblick ==<br />
Das SNA•ps Gateway macht Ressourcen, die vom Mainframe oder der AS/400 via [https://en.wikipedia.org/wiki/IBM_Systems_Network_Architecture#Physical_Unit_.28PU.29 SNA PUs] bzw. [https://en.wikipedia.org/wiki/IBM_Advanced_Peer-to-Peer_Networking APPN]/[https://en.wikipedia.org/wiki/IBM_Advanced_Program-to-Program_Communication APPC] bereit gestellt werden, im AppleTalk-Netzwerk verfügbar und umgekehrt. Somit muss nicht in jeden Mac eine (teure) Karte zur Anbindung an das SNA-Netzwerk eingebaut werden, zumal das in manchen Fällen gar nicht möglich ist (kompakte Macs wie der Plus haben keine oder nur eingeschränkte Erweiterungsmöglichkeiten. Zudem ist ggfs. die notwendige Netzwerkverkabelung evtl. nicht vorhanden.)<br /><br />
Beispiele für Clients sind die Terminalemulationen [https://en.wikipedia.org/wiki/IBM_3270 3270], [https://en.wikipedia.org/wiki/IBM_5250 5250]), die dem SNA•ps-Clientpaket beiliegen: Damit können Macs, die nur im [https://en.wikipedia.org/wiki/AppleTalk AppleTalk]-Netzwerk (z.&thinsp;B. via [https://en.wikipedia.org/wiki/LocalTalk LocalTalk]) verbunden sind, Terminalsitzungen zu den SNA-Hosts aufbauen.<br /><br />
Ein Beispiel für die umgekehrte Richtung ist die Druckunterstützung. Der SNA•ps-Print Client emuliert einen IBM 8312-Drucker. Druckjobs, die von einer Druckerqueue auf dem Host dort hin versandt werden, können je nach dem über den in der [https://en.wikipedia.org/wiki/Chooser_(Mac_OS) Auswahl] voreingestellten Drucker gedruckt, oder als Text in eine Datei gesichert werden. Dies war ein Weg, den seinerzeit sehr teuren [https://en.wikipedia.org/wiki/LaserWriter Apple LaserWriter] auch für Großrechner nutzbar zu machen.<br />
<br />
Das Gegenstück zum SNA•ps Gateway ist eine Systemerweiterung ''SNA•ps Access''. Die oben genannten Programme benutzen Routinen, welche diese Erweiterung zu Verfügung stellt. Das SNA•ps API kann somit auch von Drittanbietern genutzt werden. Ein Beispiel hierzu ist [https://en.wikipedia.org/wiki/Database_abstraction_layer DAL] für den Macintosh, welches verschiedene Protokolle für die Verbindung zur eigentlichen Datenbank benutzt; unter Anderem IP (via MacTCP) als auch SNA (via SNA•ps Access).<br />
<br />
Für die AS/400 existierten in den 1990er Jahren auch LocalTalk-Zusatzkarten und eine Erweiterung für OS/400, um den AppleTalk-Stack auch auf der AS/400 zu implementieren. Die Implementation auf der AS/400 entsprach dem SNA•ps Gateway, so dass kein Mac als Gateway benötigt wurde: Die notwendige Software lief komplett auf der AS/400.<br />
<br />
== Systemkompatibilität ==<br />
Der SNA•ps 5250 Client benötigt zwingend System 7.0 oder höher. Unter System 6 erhält man eine entsprechende Meldung und der Client startet nicht. Der 3270-Terminalclient startet klaglos unter System 6.0.7.<br />
<br />
Der Client funktioniert unter Systemen bis inkl. 8.1 und OpenTransport auf 68k-Macs. Er läuft nicht mehr auf PowerPC-Macs, der Start einer Verbindung lässt den Client mit einer ''unimplemented instruction'' abstürzen.<br />
<br />
Eine Verbindung via TCP (möglich ab Client Version 1.1) provoziert bereits beim Verbindungsaufbau die Meldung, das Gegenüber könne kein 5250-Protokoll. Nachvollziehbar unter 7.6.1/OT/PPC als auch unter 7.1/MacTCP auf 68k.<br />
<br />
Das Gateway selbst verlangt spezielle Hardware für die SNA-Netzwerkverbindung und ist daher eingeschränkt auf NuBus-Systeme.<br />
<br />
== Transport ==<br />
Folgende Verbindungsmöglichkeiten werden unterstützt:<br />
<br />
{|class="wikitable"<br />
! Phy<br />
! Bemerkungen<br />
|-<br />
|SDLC<br />
|Via Apple Serial NB-Karte<br />
|-<br />
|Token Ring<br />
|Via Apple Token Ring 4/16 NB Karte<br />
|-<br />
|Twinax<ref>5250-Sitzungen über Twinax werden nicht unterstützt. Das hätte mal implementiert werden sollen, dazu kam es allerdings nicht mehr.</ref><br />
|Via Apple Koax/Twinax Karte<br />
|}<br />
<br />
Alle diese Karten haben als Besonderheit eine eigene 68000 CPU und lokalen Speicher und entsprechen der Macintosh Coprocessor Platform Spezifikation. Auf der Karte läuft ein kleiner Prozess, welcher über ''Message Passing'' mit dem Gegenstück ''A/ROSE'' im Mac OS kommuniziert und Daten austauscht.<br />
<br />
Als Besonderheit läuft ein Teil der SNA•ps-Software auf dem Prozessor der jeweiligen Karte. Zusammen mit dem Rest der Software auf Mac OS-Seite werden APPC-Sitzungen in AppleTalk verpackt und können so auch anderen Macs im lokalen Netzwerk zu Verfügung gestellt werden. Auch über Netzwerkverbindungen, welche kein SNA unterstützen wie z.&thinsp;B. LocalTalk.<br />
<br />
<gallery mode="packed"><br />
Datei:Apple-Token-Ring-NB-Compside.jpg|Apple Token Ring 4/16 NB Karte, vorne<br />
Datei:Apple-Token-Ring-NB-Solderside.jpg|Apple Token Ring 4/16 NB Karte, hinten<br />
Datei:Apple-Coax-Twinax-Compside.jpg|Apple Coax/Twinax Karte, vorne<br />
Datei:Apple-Coax-Twinax-Solderside.jpg|Apple Coax/Twinax Karte, hinten<br />
</gallery><br />
<br />
== Konfiguration ==<br />
[[File:Cfg-snaps.gif|thumb|right|183px|Übersicht des Konfigurationsfensters]]<br />
Als Voraussetzung auf AS/400-Seite muss Autokonfiguration für Controller- und Gerätebeschreibungen erlaubt sein: Siehe dazu den Befehl WRKSYSVAL und die Variablen QAUTOCFG, QAUTORMT und QAUTOVRT. Ggfs. ist es sinnvoll, die Variablen QLMTDEVSSN und QLMTSECOFR anzupassen. Zudem wird eine funktionierende Token Ring-Verbindung vorausgesetzt. In der Leitungsbeschreibung muss der Parameter AUTOCRTCTL auf *YES stehen. Es wird empfohlen, den zugehörigen Parameter AUTODLTCTL auf *NONE zu setzen.<br /><br />
Mit dieser Vorbereitung spart man sich die mühsame und fehlerträchtige Konfiguration von OS/400-Controller (*CTLD) und -Gerät (*DEVD) für die Kommunikation mit dem Gateway auf Mac-Seite.<br />
<br />
Die Konfiguration wird mit dem Programm ''SNA•ps Config'' erstellt und schichtweise aufgebaut.<br />
<br />
Es ist problemlos möglich, mehrere AS/400 in einem Konfigurationsdokument zu erfassen. Dazu müssen pro Maschine eigene Definitionen für<br />
* TR Lines,<br />
* Partners,<br />
* Remote 6.2 LUs,<br />
* Modes<br />
erstellt werden. ''Local 6.2 LUs'' und ''TPs'' gelten für das gesamte Dokument.<br />
<br />
Ist eine Maschine im APPN-Verbund als ''Network Node'' konfiguriert, genügt eine Verbindung vom Gateway zu jener Maschine. SNA-APPC Sitzungen werden dann von dort aus weitergeleitet. Es genügt dann, die entsprechenden LUs auf dem Gateway anzulegen.<br />
<br />
=== Line ===<br />
[[File:Cfg-line.gif|thumb|right|183px|Line-Konfiguration]]<br />
Zuerst wird die ''Line''-Konfiguration erstellt. Der Name kann frei gewählt werden. Die Vergrößerung des ''Maximum I-Field Length''-Parameters erhöht den Datendurchsatz und somit die Geschwindigkeit mit welcher Daten durch das Gateway weitergereicht werden. Der höchste akzeptierte Wert ist 4105&thinsp;Bytes. In der ''Line Description'' der AS/400 (was der Line-Konfiguration von SNA•ps entspricht) steht in aller Regel 16393&thinsp;Bytes. Der tatsächlich verwendete Wert wird dynamisch ausgehandelt.<br />
<br />
=== Partner ===<br />
[[File:Cfg-peer.gif|thumb|right|183px|Partnerkonfiguration]]<br />
Solange die erstellte ''Line'' markiert ist, kann im ''Partners''-Feld nebenan die Beschreibung für die eigentliche Netzwerkverbindung zur AS/400 definiert werden. Dabei gelten folgende Parallelen zur AS/400-Konfiguration:<br />
{|class="wikitable"<br />
!Partner-Parameter<br />
!AS/400-Parameter<br />
|-<br />
|Name<br />
|DSPNETA, Name des lokalen Kontrollpunkts (LCLCPNAME)<br />
|-<br />
|Link Address<br />
|WRKLIND, Lokale Adapteradresse (der Token Ring Line) (ADPTADR)<br />
|-<br />
|Partner XID<br />
|WRKLIND, Austausch-ID (der Token Ring Line) (EXCHID)<br />
|-<br />
|Gateway XID<br />
|Selbst würfeln, muss mit 056 beginnen<ref>Dieser Wert wird beim ersten Start per Autokonfiguration auf die AS/400-seitige Controllerbeschreibung übernommen.</ref><br />
|-<br />
|Gateway Network Name<br />
|Selbst würfeln, ggfs. den Namen aus dem Kontrollfeld ''Gemeinschaftsfunktionen'' benutzen<br />
|-<br />
|Gateway Network Qualifier<br />
|DSPNETA, Lokale Netzwerk-ID (LCLNETID)<br />
|}<br />
<br />
Die Charakteristik muss auf ''Peer (Node Type 2.1)'' gesetzt werden. Die ''SAP Address'' bleibt auf 4.<br />
<br />
=== Local 6.2 LUs ===<br />
[[File:Cfg-loclu.gif|thumb|right|183px|Lokale 6.2 LUs]]<br />
{|class="wikitable"<br />
!LU-Parameter<br />
!AS/400-Parameter<br />
|-<br />
|Name: PASSTHRU (wird im Kontrollfeld SNA•ps… der Clients benutzt)<br />
|&nbsp;<br />
|-<br />
|Network LU Name = Gateway Network Name aus der Partner-Konfiguration<br />
|&nbsp;<br />
|-<br />
|Network Qualifier<br />
|DSPNETA, Lokale Netzwerk-ID (LCLNETID)<br />
|}<br />
<br />
=== TPs ===<br />
[[File:Cfg-tp.gif|thumb|right|183px|Transaction Points]]<br />
Die eben definierte ''Local 6.2 LU'' muss markiert sein, damit ein neuer ''Transaction Point'' erstellt werden kann.<br />
* Name: * (Sternchen)<br />
* Network Name = DSPNETA, Lokale Netzwerk-ID der AS/400 (LCLNETID)<br />
<br />
Rest belassen.<br />
<br />
=== Remote 6.2 LUs ===<br />
[[File:Cfg-remlu.gif|thumb|right|183px|Ferne 6.2 LUs]]<br />
Der oben erstellte ''Partner'' muss markiert sein, damit eine zugehörige LU-Konfiguration erstellt werden kann.<br />
* Name = Name des ''Partner''s<br />
* Network LU name = Name des ''Partner''s<br />
* Network Qualifier = DSPNETA, Lokale Netzwerk-ID der AS/400 (LCLNETID)<br />
<br />
Rest belassen.<br />
<br />
=== Modes ===<br />
[[File:Cfg-mode.gif|thumb|right|183px|APLSNAPS-Modusbeschreibung]]<br />
Die oben erstellte ''Remote 6.2 LU'' muss markiert sein, damit eine zugehörige Mode-Konfiguration erstellt werden kann.<br />
<br />
Auf der AS/400 gibt es keine passende Modusbeschreibung. Man muss diese daher manuell anlegen:<br />
CRTMODD MODD(APLSNAPS) COS(#CONNECT) MAXSSN(32) MAXCNV(32) LCLCTLSSN(0) INPACING(7) OUTPACING(7) TEXT('Für Apple SNA.ps')<br />
<br />
Es kann passieren, dass das Gateway nicht startet, weil der Speicher (auf der Karte) nicht ausreicht. Dann empfiehlt es sich, mit ''wrkmodd'' anzupassen: MAXSSN und LCLCTLSSN zu reduzieren. Dies muss logischerweise auch in der SNA ps-Config nachgezogen werden.<br />
<br />
== Aktivierung des Gateways ==<br />
Nachdem die Konfiguration gesichert wurde, wird diese mit dem Programm ''SNA•ps Admin'' der vorhandenen physikalischen Verbindung zugeordnet. Pro SNA-fähiger Verbindungskarte wird im eingeblendeten Fenster ''Network Gateway Status'' eine Zeile angezeigt. Die gewünschte Zeile wird markiert und danach im Menü ''Gateway'' mit ''Select configuration…'' der oben erstellten Konfiguration zugeordnet.<br /><br />
Im selben Menü wird empfohlen, über den Punkt ''Change Settings…''<br />
* dem Gateway einen schöneren Namen zuzuordnen und<br />
* alle Checkboxen bis auf ''Initially Log Line Trace'' unter ''Characteristics'' anzuknipsen.<br />
<br />
Danach kann im Menü ''Gateway'' mit ''Start Gateway'' die Gatewaysoftware gestartet werden.<br />
<br />
Es hat sich gezeigt, dass zumindest mit SNA•ps Version 1.1 das Ausprobieren von Konfigurationsinstellungen mit manuellem Stop und Start manchmal die Meldung provoziert, es wäre zu wenig Speicher vorhanden. Diese Aussage bezieht sich auf den lokalen Speicher auf der entsprechenden Netzwerkkarte. Anscheinend werden Ressourcen dort nicht zuverlässig überschrieben, nach einem Neustart des Rechners ist die Fehlermeldung weg.<br />
<br />
Ebenfalls im Menü ''Gateway'' kann nun mit ''Show Gateway'' eine Übersicht über die vorhandenen Ressourcen angezeigt werden. Ein Beispiel ist im zweiten Screenshot ab Artikelbeginn zu sehen.<br />
<br />
=== Screenshots ===<br />
<gallery mode="nolines"><br />
File:Stat-line.gif<br />
File:Stat-peer.gif<br />
File:Stat-loclu.gif<br />
File:Stat-tp.gif<br />
File:Stat-remlu.gif<br />
File:Stat-mode-snasvcmg.gif<br />
File:Stat-mode-aplsnaps.gif<br />
File:Stat-sess-snasvcmg.gif<br />
File:Stat-sess-aplsnaps.gif<br />
</gallery><br />
<br />
== Client-Konfiguration SNA•ps 5250 ==<br />
Im Kontrollfeld ''SNA•ps Access/5250'' kann in der ''Display Configuration'' auf ''Virtual Controller'' umgestellt werden. Der Controllername ist üblicherweise ''QPACTL01''.<br />
<br />
[[Datei:Dft-connsel.gif|right|thumb|Modaler Dialog zur Auswahl einer Standardsitzung]]<br />
Die Clientkonfiguration beschränkt sich auf die Auswahl der ''Default Connection'' im Menü ''Pref(erence)s''. Alternativ kann im Client die gewünschte Sitzung direkt konfiguriert werden (''Session'', ''Connection…'').<br />
<br />
Danach wird im Menü ''Session'' mit dem Punkt ''Connect'' die Verbindung zum vorab ausgewählten SNA-Gateway hergestellt. Nach einigen Sekunden wird der AS/400 Signon-Screen angezeigt.<br />
<br />
Nebenbei können dann auch noch weitere Parameter gesetzt werden: Größere Schriftart bei entsprechend großen Monitoren, alternative Tastenbelegungen für kleine Mac-Tastaturen (hier bietet sich der Zehnerblock an), usw. Die Einstellungen können in einem Verbindungsdokument gesichert werden. Beim Öffnen eines solchen Dokuments wird die Sitzung automatisch aufgebaut.<br />
<br />
Alle weiteren Einstellungen können je nach Gusto vorgenommen werden.<br />
<br />
== Client-Konfiguration SNA•ps Print ==<br />
Der Print-Client ist nur in der Paketversion 1.0 enthalten. Damit können Druckjobs flexibel gehandhabt werden.<br />
<br />
Im Kontrollfeld ''SNA•ps Access/5250'' muss in der ''Printer Configuration'', ''Printer Device List…'' ein Drucker konfiguriert werden. Dieser sollte auf der AS/400 nicht existieren, damit er mit den richtigen Parametern angelegt wird.<br />
<br />
Nach dem Start von ''SNA•ps Print'' wird nach einem Dateinamen für die nun neu angelegte Druckerverbindung gefragt. Dieses Dokument entsprechend sichern.<br />
<br />
Danach wird im Menü ''Session'' mit dem Punkt ''Connect'' die Verbindung zum vorab ausgewählten SNA-Gateway hergestellt. Die AS/400 legt eine Druckergerätedatei (*DEVD) und eine entsprechende Ausgabewarteschlange (*OUTQ) an. Alles was dort reingestellt wird, landet in der Druckroutine von SNA•ps Print.<br />
<br />
Es wird ein IBM 3812 Model 1 Drucker (SCS) emuliert.<br />
<br />
== Fehlerquellen ==<br />
* Die Benutzung von ''Trawl'' auf dem Gatewayrechner selbst bringt u.&thinsp;U. AppleTalk ins Schleudern, sodass das Gateway nicht mehr im Managertool auftaucht. Dann hilft nur ein Reboot des Gateway-Rechners.<br />
<br />
== Weblinks ==<br />
* Wikipedia (en):<br />
** [https://en.wikipedia.org/wiki/IBM_Systems_Network_Architecture IBM Systems Network Architecture]<br />
** [https://en.wikipedia.org/wiki/IBM_Advanced_Program-to-Program_Communication IBM Advanced Program-to-Program Communication]<br />
** [https://en.wikipedia.org/wiki/IBM_Advanced_Peer-to-Peer_Networking IBM Advanced Peer-to-Peer Networking]<br />
** [https://en.wikipedia.org/wiki/Synchronous_Data_Link_Control Synchronous Data Link Control]<br />
** [https://en.wikipedia.org/wiki/A/ROSE Apple Real-time Operating System Environment]<br />
** [https://en.wikipedia.org/wiki/Message_passing Message Passing]<br />
** [https://en.wikipedia.org/wiki/AppleTalk AppleTalk]<br />
** [https://en.wikipedia.org/wiki/LocalTalk LocalTalk]<br />
* [http://www.mactech.com/articles/develop/issue_04/coprocessor.html Inside The Macintosh Coprocessor Platform And A/ROSE]<br />
* [https://www.computerwoche.de/a/terminalemulation-bindet-apple-welt-an-as-400-mac-user-haben-direkten-zugriff-auf-as-400-daten,1128406 Terminalemulation bindet Apple-Welt an AS/400], Computerwoche 1993-06-11<br />
* [https://www.ibm.com/support/knowledgecenter/en/SSEQ5Y_5.9.0/com.ibm.pcomm.doc/books/html/admin_guide19.htm Administrator's Guide and Reference, SNA Client/Server Concepts], IBM<br />
* [https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.znetwork/znetwork_6.htm Introduction to networking on the mainframe], IBM<br />
* [https://web.archive.org/web/20181229140138/http://docwiki.cisco.com/wiki/IBM_Systems_Network_Architecture_Protocols IBM Systems Network Architecture Protocols], Cisco Docwiki (aus dem Archiv)<br />
<br />
== Fußnoten ==<br />
<references /><br />
<br />
[[Kategorie: AS/400]]<br />
[[Kategorie: Mac OS]]<br />
[[Kategorie: Netzwerk]]</div>PoChttps://kb.pocnet.net/index.php?title=Datei:IPCS-285A.jpg&diff=2926Datei:IPCS-285A.jpg2023-01-05T18:18:59Z<p>PoC: +Kat</p>
<hr />
<div>== Beschreibung ==<br />
Zusatzkarte für den IPCS #2850 mit den eigentlichen Schnittstellen und Chipsatz.<br />
<br />
[[Kategorie: AS/400]]</div>PoChttps://kb.pocnet.net/index.php?title=Datei:IPCS-2850-12.jpg&diff=2925Datei:IPCS-2850-12.jpg2023-01-05T18:18:51Z<p>PoC: +Kat</p>
<hr />
<div>== Beschreibung ==<br />
IPCS #2850 Haupt-Board mit 333 MHz Pentium Overdrive.<br />
<br />
[[Kategorie: AS/400]]</div>PoChttps://kb.pocnet.net/index.php?title=Apple_SNA%E2%80%A2ps_Konfiguration_f%C3%BCr_5250-Sitzungen&diff=2917Apple SNA•ps Konfiguration für 5250-Sitzungen2023-01-05T18:05:17Z<p>PoC: /* Screenshots */ Renames/neue Screenshots</p>
<hr />
<div>[[Datei:5250term.gif|thumb|right|5250 Clientverbindung via SNA•ps]]<br />
[[Datei:Snagw-run.gif|thumb|right|SNA•ps Gateway Fenster]]<br />
'''Apple SNA•ps''' ist eine Software, welche die Kommunikation von Apple Macs mit System 7.x mit IBM-Rechnersystemen ermöglicht. Die Kommunikation mit den Rechnern findet hierbei nicht wie heutzutage üblich über IP statt, sondern über Protokolle im Rahmen von '''SNA''' (Systems Network Architecture).<ref>Neuere Versionen vom SNA•ps 5250 Client unterstützen auch IP/tn5250 als Transportweg.</ref><br /><br />
Das Programmpaket wurde als Ergebnis einer erklärten Zusammenarbeit von IBM und Apple Anfang der 1990er Jahre von Orion Software programmiert.<br />
<br />
SNA•ps gibt es zum einen als Gateway mit einer lizenzabhängigen Maximalanzahl von 8, 32 oder 64 [https://en.wikipedia.org/wiki/IBM_Systems_Network_Architecture#Logical_Unit_.28LU.29 LU]-LU Sessions, zum anderen als Client für 5250 Terminal- und Druckservices als auch 3270 Terminalservices. Dieser Artikel konzentriert sich auf das Thema AS/400 bzw. 5250-Anbindung.<br />
<br />
Das SNA•ps Gateway macht Ressourcen, die vom Mainframe oder der AS/400 via [https://en.wikipedia.org/wiki/IBM_Systems_Network_Architecture#Physical_Unit_.28PU.29 SNA PUs] bzw. [https://en.wikipedia.org/wiki/IBM_Advanced_Peer-to-Peer_Networking APPN]/[https://en.wikipedia.org/wiki/IBM_Advanced_Program-to-Program_Communication APPC] bereit gestellt werden, im AppleTalk-Netzwerk verfügbar und umgekehrt. Somit muss nicht in jeden Mac eine (teure) Karte zur Anbindung an das SNA-Netzwerk eingebaut werden, zumal das in manchen Fällen gar nicht möglich ist (kompakte Macs wie der Plus haben keine oder nur eingeschränkte Erweiterungsmöglichkeiten. Zudem ist ggfs. die notwendige Netzwerkverkabelung evtl. nicht vorhanden.)<br /><br />
Beispiele für Clients sind die Terminalemulationen [https://en.wikipedia.org/wiki/IBM_3270 3270], [https://en.wikipedia.org/wiki/IBM_5250 5250]), die dem SNA•ps-Clientpaket beiliegen: Damit können Macs, die nur im [https://en.wikipedia.org/wiki/AppleTalk AppleTalk]-Netzwerk (z.&thinsp;B. via [https://en.wikipedia.org/wiki/LocalTalk LocalTalk]) verbunden sind, Terminalsitzungen zu den SNA-Hosts aufbauen.<br /><br />
Ein Beispiel für die umgekehrte Richtung ist die Druckunterstützung. Der SNA•ps-Print Client emuliert einen IBM 8312-Drucker. Druckjobs, die von einer Druckerqueue auf dem Host dort hin versandt werden, können je nach dem über den in der [https://en.wikipedia.org/wiki/Chooser_(Mac_OS) Auswahl] voreingestellten Drucker gedruckt, oder als Text in eine Datei gesichert werden. Dies war ein Weg, den seinerzeit sehr teuren [https://en.wikipedia.org/wiki/LaserWriter Apple LaserWriter] auch für Großrechner nutzbar zu machen.<br />
<br />
Das Gegenstück zum SNA•ps Gateway ist eine Systemerweiterung ''SNA•ps Access''. Die oben genannten Programme benutzen Routinen, welche diese Erweiterung zu Verfügung stellt. Das SNA•ps API kann somit auch von Drittanbietern genutzt werden. Ein Beispiel hierzu ist [https://en.wikipedia.org/wiki/Database_abstraction_layer DAL] für den Macintosh, welches verschiedene Protokolle für die Verbindung zur eigentlichen Datenbank benutzt; unter Anderem MacTCP (IP) als auch SNA (via SNA•ps Access).<br />
<br />
Für die AS/400 existierten in den 1990er Jahren auch LocalTalk-Zusatzkarten und eine Erweiterung für OS/400, um den AppleTalk-Stack auch auf der AS/400 zu implementieren. Die Implementation auf der AS/400 entsprach dem SNA•ps Gateway, so dass kein Mac als Gateway benötigt wurde: Die notwendige Software lief komplett auf der AS/400.<br />
<br />
== Systemkompatibilität ==<br />
Der SNA•ps 5250 Client benötigt zwingend System 7.0 oder höher. Unter System 6 erhält man eine entsprechende Meldung und der Client startet nicht. Der 3270-Terminalclient startet klaglos unter System 6.0.7.<br />
<br />
Der Client funktioniert unter Systemen bis inkl. 8.1 und OpenTransport auf 68k-Macs. Er läuft nicht mehr auf PowerPC-Macs, der Start einer Verbindung lässt den Client mit einer ''unimplemented instruction'' abstürzen.<br />
<br />
Eine Verbindung via TCP (möglich ab Client Version 1.1) provoziert bereits beim Verbindungsaufbau die Meldung, das Gegenüber könne kein 5250-Protokoll. Nachvollziehbar unter 7.6.1/OT/PPC als auch unter 7.1/MacTCP auf 68k.<br />
<br />
Das Gateway selbst verlangt spezielle Hardware für die SNA-Netzwerkverbindung und ist daher eingeschränkt auf NuBus-Systeme.<br />
<br />
== Transport ==<br />
Folgende Verbindungsmöglichkeiten werden unterstützt:<br />
<br />
{|class="wikitable"<br />
! Phy<br />
! Bemerkungen<br />
|-<br />
|SDLC<br />
|Via Apple Serial NB-Karte<br />
|-<br />
|Token Ring<br />
|Via Apple Token Ring 4/16 NB Karte<br />
|-<br />
|Twinax<ref>5250-Sitzungen über Twinax werden nicht unterstützt. Das hätte mal implementiert werden sollen, dazu kam es allerdings nicht mehr.</ref><br />
|Via Apple Koax/Twinax Karte<br />
|}<br />
<br />
Alle diese Karten haben als Besonderheit eine eigene 68000 CPU und lokalen Speicher und entsprechen der Macintosh Coprocessor Platform Spezifikation. Auf der Karte läuft ein kleiner Prozess, welcher über ''Message Passing'' mit dem Gegenstück ''A/ROSE'' im Mac OS kommuniziert und Daten austauscht.<br />
<br />
Als Besonderheit läuft ein Teil der SNA•ps-Software auf dem Prozessor der jeweiligen Karte. Zusammen mit dem Rest der Software auf Mac OS-Seite werden APPC-Sitzungen in AppleTalk verpackt und können so auch anderen Macs im lokalen Netzwerk zu Verfügung gestellt werden. Auch über Netzwerkverbindungen, welche kein SNA unterstützen wie z.&thinsp;B. LocalTalk.<br />
<br />
<gallery mode="packed"><br />
Datei:Apple-Token-Ring-NB-Compside.jpg|Apple Token Ring 4/16 NB Karte, vorne<br />
Datei:Apple-Token-Ring-NB-Solderside.jpg|Apple Token Ring 4/16 NB Karte, hinten<br />
Datei:Apple-Coax-Twinax-Compside.jpg|Apple Coax/Twinax Karte, vorne<br />
Datei:Apple-Coax-Twinax-Solderside.jpg|Apple Coax/Twinax Karte, hinten<br />
</gallery><br />
<br />
== Konfiguration ==<br />
[[File:Cfg-snaps.gif|thumb|right|183px|Übersicht des Konfigurationsfensters]]<br />
Als Voraussetzung auf AS/400-Seite muss Autokonfiguration für Controller- und Gerätebeschreibungen erlaubt sein: Siehe dazu den Befehl WRKSYSVAL und die Variablen QAUTOCFG, QAUTORMT und QAUTOVRT. Ggfs. ist es sinnvoll, die Variablen QLMTDEVSSN und QLMTSECOFR anzupassen. Zudem wird eine funktionierende Token Ring-Verbindung vorausgesetzt. In der Leitungsbeschreibung muss der Parameter AUTOCRTCTL auf *YES stehen. Es wird empfohlen, den zugehörigen Parameter AUTODLTCTL auf *NONE zu setzen.<br /><br />
Mit dieser Vorbereitung spart man sich die mühsame und fehlerträchtige Konfiguration von OS/400-Controller (*CTLD) und -Gerät (*DEVD) für die Kommunikation mit dem Gateway auf Mac-Seite.<br />
<br />
Die Konfiguration wird mit dem Programm ''SNA•ps Config'' erstellt und schichtweise aufgebaut.<br />
<br />
Es ist problemlos möglich, mehrere AS/400 in einem Konfigurationsdokument zu erfassen. Dazu müssen pro Maschine eigene Definitionen für<br />
* TR Lines,<br />
* Partners,<br />
* Remote 6.2 LUs,<br />
* Modes<br />
erstellt werden. ''Local 6.2 LUs'' und ''TPs'' gelten für das gesamte Dokument.<br />
<br />
Ist eine Maschine im APPN-Verbund als ''Network Node'' konfiguriert, genügt eine Verbindung vom Gateway zu jener Maschine. SNA-APPC Sitzungen werden dann von dort aus weitergeleitet. Es genügt dann, die entsprechenden LUs auf dem Gateway anzulegen.<br />
<br />
=== Line ===<br />
[[File:Cfg-line.gif|thumb|right|183px|Line-Konfiguration]]<br />
Zuerst wird die ''Line''-Konfiguration erstellt. Der Name kann frei gewählt werden. Die Vergrößerung des ''Maximum I-Field Length''-Parameters erhöht den Datendurchsatz und somit die Geschwindigkeit mit welcher Daten durch das Gateway weitergereicht werden. Der höchste akzeptierte Wert ist 4105&thinsp;Bytes. In der ''Line Description'' der AS/400 (was der Line-Konfiguration von SNA•ps entspricht) steht in aller Regel 16393&thinsp;Bytes. Der tatsächlich verwendete Wert wird dynamisch ausgehandelt.<br />
<br />
=== Partner ===<br />
[[File:Cfg-peer.gif|thumb|right|183px|Partnerkonfiguration]]<br />
Solange die erstellte ''Line'' markiert ist, kann im ''Partners''-Feld nebenan die Beschreibung für die eigentliche Netzwerkverbindung zur AS/400 definiert werden. Dabei gelten folgende Parallelen zur AS/400-Konfiguration:<br />
{|class="wikitable"<br />
!Partner-Parameter<br />
!AS/400-Parameter<br />
|-<br />
|Name<br />
|DSPNETA, Name des lokalen Kontrollpunkts (LCLCPNAME)<br />
|-<br />
|Link Address<br />
|WRKLIND, Lokale Adapteradresse (der Token Ring Line) (ADPTADR)<br />
|-<br />
|Partner XID<br />
|WRKLIND, Austausch-ID (der Token Ring Line) (EXCHID)<br />
|-<br />
|Gateway XID<br />
|Selbst würfeln, muss mit 056 beginnen<ref>Dieser Wert wird beim ersten Start per Autokonfiguration auf die AS/400-seitige Controllerbeschreibung übernommen.</ref><br />
|-<br />
|Gateway Network Name<br />
|Selbst würfeln, ggfs. den Namen aus dem Kontrollfeld ''Gemeinschaftsfunktionen'' benutzen<br />
|-<br />
|Gateway Network Qualifier<br />
|DSPNETA, Lokale Netzwerk-ID (LCLNETID)<br />
|}<br />
<br />
Die Charakteristik muss auf ''Peer (Node Type 2.1)'' gesetzt werden. Die ''SAP Address'' bleibt auf 4.<br />
<br />
=== Local 6.2 LUs ===<br />
[[File:Cfg-loclu.gif|thumb|right|183px|Lokale 6.2 LUs]]<br />
{|class="wikitable"<br />
!LU-Parameter<br />
!AS/400-Parameter<br />
|-<br />
|Name: PASSTHRU (wird im Kontrollfeld SNA•ps… der Clients benutzt)<br />
|&nbsp;<br />
|-<br />
|Network LU Name = Gateway Network Name aus der Partner-Konfiguration<br />
|&nbsp;<br />
|-<br />
|Network Qualifier<br />
|DSPNETA, Lokale Netzwerk-ID (LCLNETID)<br />
|}<br />
<br />
=== TPs ===<br />
[[File:Cfg-tp.gif|thumb|right|183px|Transaction Points]]<br />
Die eben definierte ''Local 6.2 LU'' muss markiert sein, damit ein neuer ''Transaction Point'' erstellt werden kann.<br />
* Name: * (Sternchen)<br />
* Network Name = DSPNETA, Lokale Netzwerk-ID der AS/400 (LCLNETID)<br />
<br />
Rest belassen.<br />
<br />
=== Remote 6.2 LUs ===<br />
[[File:Cfg-remlu.gif|thumb|right|183px|Ferne 6.2 LUs]]<br />
Der oben erstellte ''Partner'' muss markiert sein, damit eine zugehörige LU-Konfiguration erstellt werden kann.<br />
* Name = Name des ''Partner''s<br />
* Network LU name = Name des ''Partner''s<br />
* Network Qualifier = DSPNETA, Lokale Netzwerk-ID der AS/400 (LCLNETID)<br />
<br />
Rest belassen.<br />
<br />
=== Modes ===<br />
[[File:Cfg-mode.gif|thumb|right|183px|APLSNAPS-Modusbeschreibung]]<br />
Die oben erstellte ''Remote 6.2 LU'' muss markiert sein, damit eine zugehörige Mode-Konfiguration erstellt werden kann.<br />
<br />
Auf der AS/400 gibt es keine passende Modusbeschreibung. Man muss diese daher manuell anlegen:<br />
CRTMODD MODD(APLSNAPS) COS(#CONNECT) MAXSSN(32) MAXCNV(32) LCLCTLSSN(0) INPACING(7) OUTPACING(7) TEXT('Für Apple SNA.ps')<br />
<br />
Es kann passieren, dass das Gateway nicht startet, weil der Speicher (auf der Karte) nicht ausreicht. Dann empfiehlt es sich, mit ''wrkmodd'' anzupassen: MAXSSN und LCLCTLSSN zu reduzieren. Dies muss logischerweise auch in der SNA ps-Config nachgezogen werden.<br />
<br />
== Aktivierung des Gateways ==<br />
Nachdem die Konfiguration gesichert wurde, wird diese mit dem Programm ''SNA•ps Admin'' der vorhandenen physikalischen Verbindung zugeordnet. Pro SNA-fähiger Verbindungskarte wird im eingeblendeten Fenster ''Network Gateway Status'' eine Zeile angezeigt. Die gewünschte Zeile wird markiert und danach im Menü ''Gateway'' mit ''Select configuration…'' der oben erstellten Konfiguration zugeordnet.<br /><br />
Im selben Menü wird empfohlen, über den Punkt ''Change Settings…''<br />
* dem Gateway einen schöneren Namen zuzuordnen und<br />
* alle Checkboxen bis auf ''Initially Log Line Trace'' unter ''Characteristics'' anzuknipsen.<br />
<br />
Danach kann im Menü ''Gateway'' mit ''Start Gateway'' die Gatewaysoftware gestartet werden.<br />
<br />
Es hat sich gezeigt, dass zumindest mit SNA•ps Version 1.1 das Ausprobieren von Konfigurationsinstellungen mit manuellem Stop und Start manchmal die Meldung provoziert, es wäre zu wenig Speicher vorhanden. Diese Aussage bezieht sich auf den lokalen Speicher auf der entsprechenden Netzwerkkarte. Anscheinend werden Ressourcen dort nicht zuverlässig überschrieben, nach einem Neustart des Rechners ist die Fehlermeldung weg.<br />
<br />
Ebenfalls im Menü ''Gateway'' kann nun mit ''Show Gateway'' eine Übersicht über die vorhandenen Ressourcen angezeigt werden. Ein Beispiel ist im zweiten Screenshot ab Artikelbeginn zu sehen.<br />
<br />
=== Screenshots ===<br />
<gallery mode="nolines"><br />
File:Stat-line.gif<br />
File:Stat-peer.gif<br />
File:Stat-loclu.gif<br />
File:Stat-tp.gif<br />
File:Stat-remlu.gif<br />
File:Stat-mode-snasvcmg.gif<br />
File:Stat-mode-aplsnaps.gif<br />
File:Stat-sess-snasvcmg.gif<br />
File:Stat-sess-aplsnaps.gif<br />
</gallery><br />
<br />
== Client-Konfiguration SNA•ps 5250 ==<br />
Im Kontrollfeld ''SNA•ps Access/5250'' kann in der ''Display Configuration'' auf ''Virtual Controller'' umgestellt werden. Der Controllername ist üblicherweise ''QPACTL01''.<br />
<br />
[[Datei:Dft-connsel.gif|right|thumb|Modaler Dialog zur Auswahl einer Standardsitzung]]<br />
Die Clientkonfiguration beschränkt sich auf die Auswahl der ''Default Connection'' im Menü ''Pref(erence)s''. Alternativ kann im Client die gewünschte Sitzung direkt konfiguriert werden (''Session'', ''Connection…'').<br />
<br />
Danach wird im Menü ''Session'' mit dem Punkt ''Connect'' die Verbindung zum vorab ausgewählten SNA-Gateway hergestellt. Nach einigen Sekunden wird der AS/400 Signon-Screen angezeigt.<br />
<br />
Nebenbei können dann auch noch weitere Parameter gesetzt werden: Größere Schriftart bei entsprechend großen Monitoren, alternative Tastenbelegungen für kleine Mac-Tastaturen (hier bietet sich der Zehnerblock an), usw. Die Einstellungen können in einem Verbindungsdokument gesichert werden. Beim Öffnen eines solchen Dokuments wird die Sitzung automatisch aufgebaut.<br />
<br />
Alle weiteren Einstellungen können je nach Gusto vorgenommen werden.<br />
<br />
== Client-Konfiguration SNA•ps Print ==<br />
Der Print-Client ist nur in der Paketversion 1.0 enthalten. Damit können Druckjobs flexibel gehandhabt werden.<br />
<br />
Im Kontrollfeld ''SNA•ps Access/5250'' muss in der ''Printer Configuration'', ''Printer Device List…'' ein Drucker konfiguriert werden. Dieser sollte auf der AS/400 nicht existieren, damit er mit den richtigen Parametern angelegt wird.<br />
<br />
Nach dem Start von ''SNA•ps Print'' wird nach einem Dateinamen für die nun neu angelegte Druckerverbindung gefragt. Dieses Dokument entsprechend sichern.<br />
<br />
Danach wird im Menü ''Session'' mit dem Punkt ''Connect'' die Verbindung zum vorab ausgewählten SNA-Gateway hergestellt. Die AS/400 legt eine Druckergerätedatei (*DEVD) und eine entsprechende Ausgabewarteschlange (*OUTQ) an. Alles was dort reingestellt wird, landet in der Druckroutine von SNA•ps Print.<br />
<br />
Es wird ein IBM 3812 Model 1 Drucker (SCS) emuliert.<br />
<br />
== Fehlerquellen ==<br />
* Die Benutzung von ''Trawl'' auf dem Gatewayrechner selbst bringt u.&thinsp;U. AppleTalk ins Schleudern, sodass das Gateway nicht mehr im Managertool auftaucht. Dann hilft nur ein Reboot des Gateway-Rechners.<br />
<br />
== Weblinks ==<br />
* Wikipedia (en):<br />
** [https://en.wikipedia.org/wiki/IBM_Systems_Network_Architecture IBM Systems Network Architecture]<br />
** [https://en.wikipedia.org/wiki/IBM_Advanced_Program-to-Program_Communication IBM Advanced Program-to-Program Communication]<br />
** [https://en.wikipedia.org/wiki/IBM_Advanced_Peer-to-Peer_Networking IBM Advanced Peer-to-Peer Networking]<br />
** [https://en.wikipedia.org/wiki/Synchronous_Data_Link_Control Synchronous Data Link Control]<br />
** [https://en.wikipedia.org/wiki/A/ROSE Apple Real-time Operating System Environment]<br />
** [https://en.wikipedia.org/wiki/Message_passing Message Passing]<br />
** [https://en.wikipedia.org/wiki/AppleTalk AppleTalk]<br />
** [https://en.wikipedia.org/wiki/LocalTalk LocalTalk]<br />
* [http://www.mactech.com/articles/develop/issue_04/coprocessor.html Inside The Macintosh Coprocessor Platform And A/ROSE]<br />
* [https://www.computerwoche.de/a/terminalemulation-bindet-apple-welt-an-as-400-mac-user-haben-direkten-zugriff-auf-as-400-daten,1128406 Terminalemulation bindet Apple-Welt an AS/400], Computerwoche 1993-06-11<br />
* [https://www.ibm.com/support/knowledgecenter/en/SSEQ5Y_5.9.0/com.ibm.pcomm.doc/books/html/admin_guide19.htm Administrator's Guide and Reference, SNA Client/Server Concepts], IBM<br />
* [https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.znetwork/znetwork_6.htm Introduction to networking on the mainframe], IBM<br />
* [https://web.archive.org/web/20181229140138/http://docwiki.cisco.com/wiki/IBM_Systems_Network_Architecture_Protocols IBM Systems Network Architecture Protocols], Cisco Docwiki (aus dem Archiv)<br />
<br />
== Fußnoten ==<br />
<references /><br />
<br />
[[Kategorie: AS/400]]<br />
[[Kategorie: Mac OS]]<br />
[[Kategorie: Netzwerk]]</div>PoChttps://kb.pocnet.net/index.php?title=Apple_SNA%E2%80%A2ps_Konfiguration_f%C3%BCr_5250-Sitzungen&diff=2913Apple SNA•ps Konfiguration für 5250-Sitzungen2023-01-05T17:51:14Z<p>PoC: /* Modes */ Eigener Mode</p>
<hr />
<div>[[Datei:5250term.gif|thumb|right|5250 Clientverbindung via SNA•ps]]<br />
[[Datei:Snagw-run.gif|thumb|right|SNA•ps Gateway Fenster]]<br />
'''Apple SNA•ps''' ist eine Software, welche die Kommunikation von Apple Macs mit System 7.x mit IBM-Rechnersystemen ermöglicht. Die Kommunikation mit den Rechnern findet hierbei nicht wie heutzutage üblich über IP statt, sondern über Protokolle im Rahmen von '''SNA''' (Systems Network Architecture).<ref>Neuere Versionen vom SNA•ps 5250 Client unterstützen auch IP/tn5250 als Transportweg.</ref><br /><br />
Das Programmpaket wurde als Ergebnis einer erklärten Zusammenarbeit von IBM und Apple Anfang der 1990er Jahre von Orion Software programmiert.<br />
<br />
SNA•ps gibt es zum einen als Gateway mit einer lizenzabhängigen Maximalanzahl von 8, 32 oder 64 [https://en.wikipedia.org/wiki/IBM_Systems_Network_Architecture#Logical_Unit_.28LU.29 LU]-LU Sessions, zum anderen als Client für 5250 Terminal- und Druckservices als auch 3270 Terminalservices. Dieser Artikel konzentriert sich auf das Thema AS/400 bzw. 5250-Anbindung.<br />
<br />
Das SNA•ps Gateway macht Ressourcen, die vom Mainframe oder der AS/400 via [https://en.wikipedia.org/wiki/IBM_Systems_Network_Architecture#Physical_Unit_.28PU.29 SNA PUs] bzw. [https://en.wikipedia.org/wiki/IBM_Advanced_Peer-to-Peer_Networking APPN]/[https://en.wikipedia.org/wiki/IBM_Advanced_Program-to-Program_Communication APPC] bereit gestellt werden, im AppleTalk-Netzwerk verfügbar und umgekehrt. Somit muss nicht in jeden Mac eine (teure) Karte zur Anbindung an das SNA-Netzwerk eingebaut werden, zumal das in manchen Fällen gar nicht möglich ist (kompakte Macs wie der Plus haben keine oder nur eingeschränkte Erweiterungsmöglichkeiten. Zudem ist ggfs. die notwendige Netzwerkverkabelung evtl. nicht vorhanden.)<br /><br />
Beispiele für Clients sind die Terminalemulationen [https://en.wikipedia.org/wiki/IBM_3270 3270], [https://en.wikipedia.org/wiki/IBM_5250 5250]), die dem SNA•ps-Clientpaket beiliegen: Damit können Macs, die nur im [https://en.wikipedia.org/wiki/AppleTalk AppleTalk]-Netzwerk (z.&thinsp;B. via [https://en.wikipedia.org/wiki/LocalTalk LocalTalk]) verbunden sind, Terminalsitzungen zu den SNA-Hosts aufbauen.<br /><br />
Ein Beispiel für die umgekehrte Richtung ist die Druckunterstützung. Der SNA•ps-Print Client emuliert einen IBM 8312-Drucker. Druckjobs, die von einer Druckerqueue auf dem Host dort hin versandt werden, können je nach dem über den in der [https://en.wikipedia.org/wiki/Chooser_(Mac_OS) Auswahl] voreingestellten Drucker gedruckt, oder als Text in eine Datei gesichert werden. Dies war ein Weg, den seinerzeit sehr teuren [https://en.wikipedia.org/wiki/LaserWriter Apple LaserWriter] auch für Großrechner nutzbar zu machen.<br />
<br />
Das Gegenstück zum SNA•ps Gateway ist eine Systemerweiterung ''SNA•ps Access''. Die oben genannten Programme benutzen Routinen, welche diese Erweiterung zu Verfügung stellt. Das SNA•ps API kann somit auch von Drittanbietern genutzt werden. Ein Beispiel hierzu ist [https://en.wikipedia.org/wiki/Database_abstraction_layer DAL] für den Macintosh, welches verschiedene Protokolle für die Verbindung zur eigentlichen Datenbank benutzt; unter Anderem MacTCP (IP) als auch SNA (via SNA•ps Access).<br />
<br />
Für die AS/400 existierten in den 1990er Jahren auch LocalTalk-Zusatzkarten und eine Erweiterung für OS/400, um den AppleTalk-Stack auch auf der AS/400 zu implementieren. Die Implementation auf der AS/400 entsprach dem SNA•ps Gateway, so dass kein Mac als Gateway benötigt wurde: Die notwendige Software lief komplett auf der AS/400.<br />
<br />
== Systemkompatibilität ==<br />
Der SNA•ps 5250 Client benötigt zwingend System 7.0 oder höher. Unter System 6 erhält man eine entsprechende Meldung und der Client startet nicht. Der 3270-Terminalclient startet klaglos unter System 6.0.7.<br />
<br />
Der Client funktioniert unter Systemen bis inkl. 8.1 und OpenTransport auf 68k-Macs. Er läuft nicht mehr auf PowerPC-Macs, der Start einer Verbindung lässt den Client mit einer ''unimplemented instruction'' abstürzen.<br />
<br />
Eine Verbindung via TCP (möglich ab Client Version 1.1) provoziert bereits beim Verbindungsaufbau die Meldung, das Gegenüber könne kein 5250-Protokoll. Nachvollziehbar unter 7.6.1/OT/PPC als auch unter 7.1/MacTCP auf 68k.<br />
<br />
Das Gateway selbst verlangt spezielle Hardware für die SNA-Netzwerkverbindung und ist daher eingeschränkt auf NuBus-Systeme.<br />
<br />
== Transport ==<br />
Folgende Verbindungsmöglichkeiten werden unterstützt:<br />
<br />
{|class="wikitable"<br />
! Phy<br />
! Bemerkungen<br />
|-<br />
|SDLC<br />
|Via Apple Serial NB-Karte<br />
|-<br />
|Token Ring<br />
|Via Apple Token Ring 4/16 NB Karte<br />
|-<br />
|Twinax<ref>5250-Sitzungen über Twinax werden nicht unterstützt. Das hätte mal implementiert werden sollen, dazu kam es allerdings nicht mehr.</ref><br />
|Via Apple Koax/Twinax Karte<br />
|}<br />
<br />
Alle diese Karten haben als Besonderheit eine eigene 68000 CPU und lokalen Speicher und entsprechen der Macintosh Coprocessor Platform Spezifikation. Auf der Karte läuft ein kleiner Prozess, welcher über ''Message Passing'' mit dem Gegenstück ''A/ROSE'' im Mac OS kommuniziert und Daten austauscht.<br />
<br />
Als Besonderheit läuft ein Teil der SNA•ps-Software auf dem Prozessor der jeweiligen Karte. Zusammen mit dem Rest der Software auf Mac OS-Seite werden APPC-Sitzungen in AppleTalk verpackt und können so auch anderen Macs im lokalen Netzwerk zu Verfügung gestellt werden. Auch über Netzwerkverbindungen, welche kein SNA unterstützen wie z.&thinsp;B. LocalTalk.<br />
<br />
<gallery mode="packed"><br />
Datei:Apple-Token-Ring-NB-Compside.jpg|Apple Token Ring 4/16 NB Karte, vorne<br />
Datei:Apple-Token-Ring-NB-Solderside.jpg|Apple Token Ring 4/16 NB Karte, hinten<br />
Datei:Apple-Coax-Twinax-Compside.jpg|Apple Coax/Twinax Karte, vorne<br />
Datei:Apple-Coax-Twinax-Solderside.jpg|Apple Coax/Twinax Karte, hinten<br />
</gallery><br />
<br />
== Konfiguration ==<br />
[[File:Cfg-snaps.gif|thumb|right|183px|Übersicht des Konfigurationsfensters]]<br />
Als Voraussetzung auf AS/400-Seite muss Autokonfiguration für Controller- und Gerätebeschreibungen erlaubt sein: Siehe dazu den Befehl WRKSYSVAL und die Variablen QAUTOCFG, QAUTORMT und QAUTOVRT. Ggfs. ist es sinnvoll, die Variablen QLMTDEVSSN und QLMTSECOFR anzupassen. Zudem wird eine funktionierende Token Ring-Verbindung vorausgesetzt. In der Leitungsbeschreibung muss der Parameter AUTOCRTCTL auf *YES stehen. Es wird empfohlen, den zugehörigen Parameter AUTODLTCTL auf *NONE zu setzen.<br /><br />
Mit dieser Vorbereitung spart man sich die mühsame und fehlerträchtige Konfiguration von OS/400-Controller (*CTLD) und -Gerät (*DEVD) für die Kommunikation mit dem Gateway auf Mac-Seite.<br />
<br />
Die Konfiguration wird mit dem Programm ''SNA•ps Config'' erstellt und schichtweise aufgebaut.<br />
<br />
Es ist problemlos möglich, mehrere AS/400 in einem Konfigurationsdokument zu erfassen. Dazu müssen pro Maschine eigene Definitionen für<br />
* TR Lines,<br />
* Partners,<br />
* Remote 6.2 LUs,<br />
* Modes<br />
erstellt werden. ''Local 6.2 LUs'' und ''TPs'' gelten für das gesamte Dokument.<br />
<br />
Ist eine Maschine im APPN-Verbund als ''Network Node'' konfiguriert, genügt eine Verbindung vom Gateway zu jener Maschine. SNA-APPC Sitzungen werden dann von dort aus weitergeleitet. Es genügt dann, die entsprechenden LUs auf dem Gateway anzulegen.<br />
<br />
=== Line ===<br />
[[File:Cfg-line.gif|thumb|right|183px|Line-Konfiguration]]<br />
Zuerst wird die ''Line''-Konfiguration erstellt. Der Name kann frei gewählt werden. Die Vergrößerung des ''Maximum I-Field Length''-Parameters erhöht den Datendurchsatz und somit die Geschwindigkeit mit welcher Daten durch das Gateway weitergereicht werden. Der höchste akzeptierte Wert ist 4105&thinsp;Bytes. In der ''Line Description'' der AS/400 (was der Line-Konfiguration von SNA•ps entspricht) steht in aller Regel 16393&thinsp;Bytes. Der tatsächlich verwendete Wert wird dynamisch ausgehandelt.<br />
<br />
=== Partner ===<br />
[[File:Cfg-peer.gif|thumb|right|183px|Partnerkonfiguration]]<br />
Solange die erstellte ''Line'' markiert ist, kann im ''Partners''-Feld nebenan die Beschreibung für die eigentliche Netzwerkverbindung zur AS/400 definiert werden. Dabei gelten folgende Parallelen zur AS/400-Konfiguration:<br />
{|class="wikitable"<br />
!Partner-Parameter<br />
!AS/400-Parameter<br />
|-<br />
|Name<br />
|DSPNETA, Name des lokalen Kontrollpunkts (LCLCPNAME)<br />
|-<br />
|Link Address<br />
|WRKLIND, Lokale Adapteradresse (der Token Ring Line) (ADPTADR)<br />
|-<br />
|Partner XID<br />
|WRKLIND, Austausch-ID (der Token Ring Line) (EXCHID)<br />
|-<br />
|Gateway XID<br />
|Selbst würfeln, muss mit 056 beginnen<ref>Dieser Wert wird beim ersten Start per Autokonfiguration auf die AS/400-seitige Controllerbeschreibung übernommen.</ref><br />
|-<br />
|Gateway Network Name<br />
|Selbst würfeln, ggfs. den Namen aus dem Kontrollfeld ''Gemeinschaftsfunktionen'' benutzen<br />
|-<br />
|Gateway Network Qualifier<br />
|DSPNETA, Lokale Netzwerk-ID (LCLNETID)<br />
|}<br />
<br />
Die Charakteristik muss auf ''Peer (Node Type 2.1)'' gesetzt werden. Die ''SAP Address'' bleibt auf 4.<br />
<br />
=== Local 6.2 LUs ===<br />
[[File:Cfg-loclu.gif|thumb|right|183px|Lokale 6.2 LUs]]<br />
{|class="wikitable"<br />
!LU-Parameter<br />
!AS/400-Parameter<br />
|-<br />
|Name: PASSTHRU (wird im Kontrollfeld SNA•ps… der Clients benutzt)<br />
|&nbsp;<br />
|-<br />
|Network LU Name = Gateway Network Name aus der Partner-Konfiguration<br />
|&nbsp;<br />
|-<br />
|Network Qualifier<br />
|DSPNETA, Lokale Netzwerk-ID (LCLNETID)<br />
|}<br />
<br />
=== TPs ===<br />
[[File:Cfg-tp.gif|thumb|right|183px|Transaction Points]]<br />
Die eben definierte ''Local 6.2 LU'' muss markiert sein, damit ein neuer ''Transaction Point'' erstellt werden kann.<br />
* Name: * (Sternchen)<br />
* Network Name = DSPNETA, Lokale Netzwerk-ID der AS/400 (LCLNETID)<br />
<br />
Rest belassen.<br />
<br />
=== Remote 6.2 LUs ===<br />
[[File:Cfg-remlu.gif|thumb|right|183px|Ferne 6.2 LUs]]<br />
Der oben erstellte ''Partner'' muss markiert sein, damit eine zugehörige LU-Konfiguration erstellt werden kann.<br />
* Name = Name des ''Partner''s<br />
* Network LU name = Name des ''Partner''s<br />
* Network Qualifier = DSPNETA, Lokale Netzwerk-ID der AS/400 (LCLNETID)<br />
<br />
Rest belassen.<br />
<br />
=== Modes ===<br />
[[File:Cfg-mode.gif|thumb|right|183px|APLSNAPS-Modusbeschreibung]]<br />
Die oben erstellte ''Remote 6.2 LU'' muss markiert sein, damit eine zugehörige Mode-Konfiguration erstellt werden kann.<br />
<br />
Auf der AS/400 gibt es keine passende Modusbeschreibung. Man muss diese daher manuell anlegen:<br />
CRTMODD MODD(APLSNAPS) COS(#CONNECT) MAXSSN(32) MAXCNV(32) LCLCTLSSN(0) INPACING(7) OUTPACING(7) TEXT('Für Apple SNA.ps')<br />
<br />
Es kann passieren, dass das Gateway nicht startet, weil der Speicher (auf der Karte) nicht ausreicht. Dann empfiehlt es sich, mit ''wrkmodd'' anzupassen: MAXSSN und LCLCTLSSN zu reduzieren. Dies muss logischerweise auch in der SNA ps-Config nachgezogen werden.<br />
<br />
== Aktivierung des Gateways ==<br />
Nachdem die Konfiguration gesichert wurde, wird diese mit dem Programm ''SNA•ps Admin'' der vorhandenen physikalischen Verbindung zugeordnet. Pro SNA-fähiger Verbindungskarte wird im eingeblendeten Fenster ''Network Gateway Status'' eine Zeile angezeigt. Die gewünschte Zeile wird markiert und danach im Menü ''Gateway'' mit ''Select configuration…'' der oben erstellten Konfiguration zugeordnet.<br /><br />
Im selben Menü wird empfohlen, über den Punkt ''Change Settings…''<br />
* dem Gateway einen schöneren Namen zuzuordnen und<br />
* alle Checkboxen bis auf ''Initially Log Line Trace'' unter ''Characteristics'' anzuknipsen.<br />
<br />
Danach kann im Menü ''Gateway'' mit ''Start Gateway'' die Gatewaysoftware gestartet werden.<br />
<br />
Es hat sich gezeigt, dass zumindest mit SNA•ps Version 1.1 das Ausprobieren von Konfigurationsinstellungen mit manuellem Stop und Start manchmal die Meldung provoziert, es wäre zu wenig Speicher vorhanden. Diese Aussage bezieht sich auf den lokalen Speicher auf der entsprechenden Netzwerkkarte. Anscheinend werden Ressourcen dort nicht zuverlässig überschrieben, nach einem Neustart des Rechners ist die Fehlermeldung weg.<br />
<br />
Ebenfalls im Menü ''Gateway'' kann nun mit ''Show Gateway'' eine Übersicht über die vorhandenen Ressourcen angezeigt werden. Ein Beispiel ist im zweiten Screenshot ab Artikelbeginn zu sehen.<br />
<br />
=== Screenshots ===<br />
<gallery mode="nolines"><br />
File:Stat-line.gif<br />
File:Stat-peer.gif<br />
File:Stat-loclu.gif<br />
File:Stat-tp.gif<br />
File:Stat-remlu.gif<br />
File:Stat-mode-snasvcmg.gif<br />
File:Stat-mode-batchsc.gif<br />
File:Stat-mode-intersc.gif<br />
File:Stat-sess-batchsc.gif<br />
File:Stat-sess-intersc.gif<br />
</gallery><br />
<br />
== Client-Konfiguration SNA•ps 5250 ==<br />
Im Kontrollfeld ''SNA•ps Access/5250'' kann in der ''Display Configuration'' auf ''Virtual Controller'' umgestellt werden. Der Controllername ist üblicherweise ''QPACTL01''.<br />
<br />
[[Datei:Dft-connsel.gif|right|thumb|Modaler Dialog zur Auswahl einer Standardsitzung]]<br />
Die Clientkonfiguration beschränkt sich auf die Auswahl der ''Default Connection'' im Menü ''Pref(erence)s''. Alternativ kann im Client die gewünschte Sitzung direkt konfiguriert werden (''Session'', ''Connection…'').<br />
<br />
Danach wird im Menü ''Session'' mit dem Punkt ''Connect'' die Verbindung zum vorab ausgewählten SNA-Gateway hergestellt. Nach einigen Sekunden wird der AS/400 Signon-Screen angezeigt.<br />
<br />
Nebenbei können dann auch noch weitere Parameter gesetzt werden: Größere Schriftart bei entsprechend großen Monitoren, alternative Tastenbelegungen für kleine Mac-Tastaturen (hier bietet sich der Zehnerblock an), usw. Die Einstellungen können in einem Verbindungsdokument gesichert werden. Beim Öffnen eines solchen Dokuments wird die Sitzung automatisch aufgebaut.<br />
<br />
Alle weiteren Einstellungen können je nach Gusto vorgenommen werden.<br />
<br />
== Client-Konfiguration SNA•ps Print ==<br />
Der Print-Client ist nur in der Paketversion 1.0 enthalten. Damit können Druckjobs flexibel gehandhabt werden.<br />
<br />
Im Kontrollfeld ''SNA•ps Access/5250'' muss in der ''Printer Configuration'', ''Printer Device List…'' ein Drucker konfiguriert werden. Dieser sollte auf der AS/400 nicht existieren, damit er mit den richtigen Parametern angelegt wird.<br />
<br />
Nach dem Start von ''SNA•ps Print'' wird nach einem Dateinamen für die nun neu angelegte Druckerverbindung gefragt. Dieses Dokument entsprechend sichern.<br />
<br />
Danach wird im Menü ''Session'' mit dem Punkt ''Connect'' die Verbindung zum vorab ausgewählten SNA-Gateway hergestellt. Die AS/400 legt eine Druckergerätedatei (*DEVD) und eine entsprechende Ausgabewarteschlange (*OUTQ) an. Alles was dort reingestellt wird, landet in der Druckroutine von SNA•ps Print.<br />
<br />
Es wird ein IBM 3812 Model 1 Drucker (SCS) emuliert.<br />
<br />
== Fehlerquellen ==<br />
* Die Benutzung von ''Trawl'' auf dem Gatewayrechner selbst bringt u.&thinsp;U. AppleTalk ins Schleudern, sodass das Gateway nicht mehr im Managertool auftaucht. Dann hilft nur ein Reboot des Gateway-Rechners.<br />
<br />
== Weblinks ==<br />
* Wikipedia (en):<br />
** [https://en.wikipedia.org/wiki/IBM_Systems_Network_Architecture IBM Systems Network Architecture]<br />
** [https://en.wikipedia.org/wiki/IBM_Advanced_Program-to-Program_Communication IBM Advanced Program-to-Program Communication]<br />
** [https://en.wikipedia.org/wiki/IBM_Advanced_Peer-to-Peer_Networking IBM Advanced Peer-to-Peer Networking]<br />
** [https://en.wikipedia.org/wiki/Synchronous_Data_Link_Control Synchronous Data Link Control]<br />
** [https://en.wikipedia.org/wiki/A/ROSE Apple Real-time Operating System Environment]<br />
** [https://en.wikipedia.org/wiki/Message_passing Message Passing]<br />
** [https://en.wikipedia.org/wiki/AppleTalk AppleTalk]<br />
** [https://en.wikipedia.org/wiki/LocalTalk LocalTalk]<br />
* [http://www.mactech.com/articles/develop/issue_04/coprocessor.html Inside The Macintosh Coprocessor Platform And A/ROSE]<br />
* [https://www.computerwoche.de/a/terminalemulation-bindet-apple-welt-an-as-400-mac-user-haben-direkten-zugriff-auf-as-400-daten,1128406 Terminalemulation bindet Apple-Welt an AS/400], Computerwoche 1993-06-11<br />
* [https://www.ibm.com/support/knowledgecenter/en/SSEQ5Y_5.9.0/com.ibm.pcomm.doc/books/html/admin_guide19.htm Administrator's Guide and Reference, SNA Client/Server Concepts], IBM<br />
* [https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.znetwork/znetwork_6.htm Introduction to networking on the mainframe], IBM<br />
* [https://web.archive.org/web/20181229140138/http://docwiki.cisco.com/wiki/IBM_Systems_Network_Architecture_Protocols IBM Systems Network Architecture Protocols], Cisco Docwiki (aus dem Archiv)<br />
<br />
== Fußnoten ==<br />
<references /><br />
<br />
[[Kategorie: AS/400]]<br />
[[Kategorie: Mac OS]]<br />
[[Kategorie: Netzwerk]]</div>PoChttps://kb.pocnet.net/index.php?title=Apple_SNA%E2%80%A2ps_Konfiguration_f%C3%BCr_5250-Sitzungen&diff=2909Apple SNA•ps Konfiguration für 5250-Sitzungen2023-01-05T17:32:25Z<p>PoC: Bild raus</p>
<hr />
<div>[[Datei:5250term.gif|thumb|right|5250 Clientverbindung via SNA•ps]]<br />
[[Datei:Snagw-run.gif|thumb|right|SNA•ps Gateway Fenster]]<br />
'''Apple SNA•ps''' ist eine Software, welche die Kommunikation von Apple Macs mit System 7.x mit IBM-Rechnersystemen ermöglicht. Die Kommunikation mit den Rechnern findet hierbei nicht wie heutzutage üblich über IP statt, sondern über Protokolle im Rahmen von '''SNA''' (Systems Network Architecture).<ref>Neuere Versionen vom SNA•ps 5250 Client unterstützen auch IP/tn5250 als Transportweg.</ref><br /><br />
Das Programmpaket wurde als Ergebnis einer erklärten Zusammenarbeit von IBM und Apple Anfang der 1990er Jahre von Orion Software programmiert.<br />
<br />
SNA•ps gibt es zum einen als Gateway mit einer lizenzabhängigen Maximalanzahl von 8, 32 oder 64 [https://en.wikipedia.org/wiki/IBM_Systems_Network_Architecture#Logical_Unit_.28LU.29 LU]-LU Sessions, zum anderen als Client für 5250 Terminal- und Druckservices als auch 3270 Terminalservices. Dieser Artikel konzentriert sich auf das Thema AS/400 bzw. 5250-Anbindung.<br />
<br />
Das SNA•ps Gateway macht Ressourcen, die vom Mainframe oder der AS/400 via [https://en.wikipedia.org/wiki/IBM_Systems_Network_Architecture#Physical_Unit_.28PU.29 SNA PUs] bzw. [https://en.wikipedia.org/wiki/IBM_Advanced_Peer-to-Peer_Networking APPN]/[https://en.wikipedia.org/wiki/IBM_Advanced_Program-to-Program_Communication APPC] bereit gestellt werden, im AppleTalk-Netzwerk verfügbar und umgekehrt. Somit muss nicht in jeden Mac eine (teure) Karte zur Anbindung an das SNA-Netzwerk eingebaut werden, zumal das in manchen Fällen gar nicht möglich ist (kompakte Macs wie der Plus haben keine oder nur eingeschränkte Erweiterungsmöglichkeiten. Zudem ist ggfs. die notwendige Netzwerkverkabelung evtl. nicht vorhanden.)<br /><br />
Beispiele für Clients sind die Terminalemulationen [https://en.wikipedia.org/wiki/IBM_3270 3270], [https://en.wikipedia.org/wiki/IBM_5250 5250]), die dem SNA•ps-Clientpaket beiliegen: Damit können Macs, die nur im [https://en.wikipedia.org/wiki/AppleTalk AppleTalk]-Netzwerk (z.&thinsp;B. via [https://en.wikipedia.org/wiki/LocalTalk LocalTalk]) verbunden sind, Terminalsitzungen zu den SNA-Hosts aufbauen.<br /><br />
Ein Beispiel für die umgekehrte Richtung ist die Druckunterstützung. Der SNA•ps-Print Client emuliert einen IBM 8312-Drucker. Druckjobs, die von einer Druckerqueue auf dem Host dort hin versandt werden, können je nach dem über den in der [https://en.wikipedia.org/wiki/Chooser_(Mac_OS) Auswahl] voreingestellten Drucker gedruckt, oder als Text in eine Datei gesichert werden. Dies war ein Weg, den seinerzeit sehr teuren [https://en.wikipedia.org/wiki/LaserWriter Apple LaserWriter] auch für Großrechner nutzbar zu machen.<br />
<br />
Das Gegenstück zum SNA•ps Gateway ist eine Systemerweiterung ''SNA•ps Access''. Die oben genannten Programme benutzen Routinen, welche diese Erweiterung zu Verfügung stellt. Das SNA•ps API kann somit auch von Drittanbietern genutzt werden. Ein Beispiel hierzu ist [https://en.wikipedia.org/wiki/Database_abstraction_layer DAL] für den Macintosh, welches verschiedene Protokolle für die Verbindung zur eigentlichen Datenbank benutzt; unter Anderem MacTCP (IP) als auch SNA (via SNA•ps Access).<br />
<br />
Für die AS/400 existierten in den 1990er Jahren auch LocalTalk-Zusatzkarten und eine Erweiterung für OS/400, um den AppleTalk-Stack auch auf der AS/400 zu implementieren. Die Implementation auf der AS/400 entsprach dem SNA•ps Gateway, so dass kein Mac als Gateway benötigt wurde: Die notwendige Software lief komplett auf der AS/400.<br />
<br />
== Systemkompatibilität ==<br />
Der SNA•ps 5250 Client benötigt zwingend System 7.0 oder höher. Unter System 6 erhält man eine entsprechende Meldung und der Client startet nicht. Der 3270-Terminalclient startet klaglos unter System 6.0.7.<br />
<br />
Der Client funktioniert unter Systemen bis inkl. 8.1 und OpenTransport auf 68k-Macs. Er läuft nicht mehr auf PowerPC-Macs, der Start einer Verbindung lässt den Client mit einer ''unimplemented instruction'' abstürzen.<br />
<br />
Eine Verbindung via TCP (möglich ab Client Version 1.1) provoziert bereits beim Verbindungsaufbau die Meldung, das Gegenüber könne kein 5250-Protokoll. Nachvollziehbar unter 7.6.1/OT/PPC als auch unter 7.1/MacTCP auf 68k.<br />
<br />
Das Gateway selbst verlangt spezielle Hardware für die SNA-Netzwerkverbindung und ist daher eingeschränkt auf NuBus-Systeme.<br />
<br />
== Transport ==<br />
Folgende Verbindungsmöglichkeiten werden unterstützt:<br />
<br />
{|class="wikitable"<br />
! Phy<br />
! Bemerkungen<br />
|-<br />
|SDLC<br />
|Via Apple Serial NB-Karte<br />
|-<br />
|Token Ring<br />
|Via Apple Token Ring 4/16 NB Karte<br />
|-<br />
|Twinax<ref>5250-Sitzungen über Twinax werden nicht unterstützt. Das hätte mal implementiert werden sollen, dazu kam es allerdings nicht mehr.</ref><br />
|Via Apple Koax/Twinax Karte<br />
|}<br />
<br />
Alle diese Karten haben als Besonderheit eine eigene 68000 CPU und lokalen Speicher und entsprechen der Macintosh Coprocessor Platform Spezifikation. Auf der Karte läuft ein kleiner Prozess, welcher über ''Message Passing'' mit dem Gegenstück ''A/ROSE'' im Mac OS kommuniziert und Daten austauscht.<br />
<br />
Als Besonderheit läuft ein Teil der SNA•ps-Software auf dem Prozessor der jeweiligen Karte. Zusammen mit dem Rest der Software auf Mac OS-Seite werden APPC-Sitzungen in AppleTalk verpackt und können so auch anderen Macs im lokalen Netzwerk zu Verfügung gestellt werden. Auch über Netzwerkverbindungen, welche kein SNA unterstützen wie z.&thinsp;B. LocalTalk.<br />
<br />
<gallery mode="packed"><br />
Datei:Apple-Token-Ring-NB-Compside.jpg|Apple Token Ring 4/16 NB Karte, vorne<br />
Datei:Apple-Token-Ring-NB-Solderside.jpg|Apple Token Ring 4/16 NB Karte, hinten<br />
Datei:Apple-Coax-Twinax-Compside.jpg|Apple Coax/Twinax Karte, vorne<br />
Datei:Apple-Coax-Twinax-Solderside.jpg|Apple Coax/Twinax Karte, hinten<br />
</gallery><br />
<br />
== Konfiguration ==<br />
[[File:Cfg-snaps.gif|thumb|right|183px|Übersicht des Konfigurationsfensters]]<br />
Als Voraussetzung auf AS/400-Seite muss Autokonfiguration für Controller- und Gerätebeschreibungen erlaubt sein: Siehe dazu den Befehl WRKSYSVAL und die Variablen QAUTOCFG, QAUTORMT und QAUTOVRT. Ggfs. ist es sinnvoll, die Variablen QLMTDEVSSN und QLMTSECOFR anzupassen. Zudem wird eine funktionierende Token Ring-Verbindung vorausgesetzt. In der Leitungsbeschreibung muss der Parameter AUTOCRTCTL auf *YES stehen. Es wird empfohlen, den zugehörigen Parameter AUTODLTCTL auf *NONE zu setzen.<br /><br />
Mit dieser Vorbereitung spart man sich die mühsame und fehlerträchtige Konfiguration von OS/400-Controller (*CTLD) und -Gerät (*DEVD) für die Kommunikation mit dem Gateway auf Mac-Seite.<br />
<br />
Die Konfiguration wird mit dem Programm ''SNA•ps Config'' erstellt und schichtweise aufgebaut.<br />
<br />
Es ist problemlos möglich, mehrere AS/400 in einem Konfigurationsdokument zu erfassen. Dazu müssen pro Maschine eigene Definitionen für<br />
* TR Lines,<br />
* Partners,<br />
* Remote 6.2 LUs,<br />
* Modes<br />
erstellt werden. ''Local 6.2 LUs'' und ''TPs'' gelten für das gesamte Dokument.<br />
<br />
Ist eine Maschine im APPN-Verbund als ''Network Node'' konfiguriert, genügt eine Verbindung vom Gateway zu jener Maschine. SNA-APPC Sitzungen werden dann von dort aus weitergeleitet. Es genügt dann, die entsprechenden LUs auf dem Gateway anzulegen.<br />
<br />
=== Line ===<br />
[[File:Cfg-line.gif|thumb|right|183px|Line-Konfiguration]]<br />
Zuerst wird die ''Line''-Konfiguration erstellt. Der Name kann frei gewählt werden. Die Vergrößerung des ''Maximum I-Field Length''-Parameters erhöht den Datendurchsatz und somit die Geschwindigkeit mit welcher Daten durch das Gateway weitergereicht werden. Der höchste akzeptierte Wert ist 4105&thinsp;Bytes. In der ''Line Description'' der AS/400 (was der Line-Konfiguration von SNA•ps entspricht) steht in aller Regel 16393&thinsp;Bytes. Der tatsächlich verwendete Wert wird dynamisch ausgehandelt.<br />
<br />
=== Partner ===<br />
[[File:Cfg-peer.gif|thumb|right|183px|Partnerkonfiguration]]<br />
Solange die erstellte ''Line'' markiert ist, kann im ''Partners''-Feld nebenan die Beschreibung für die eigentliche Netzwerkverbindung zur AS/400 definiert werden. Dabei gelten folgende Parallelen zur AS/400-Konfiguration:<br />
{|class="wikitable"<br />
!Partner-Parameter<br />
!AS/400-Parameter<br />
|-<br />
|Name<br />
|DSPNETA, Name des lokalen Kontrollpunkts (LCLCPNAME)<br />
|-<br />
|Link Address<br />
|WRKLIND, Lokale Adapteradresse (der Token Ring Line) (ADPTADR)<br />
|-<br />
|Partner XID<br />
|WRKLIND, Austausch-ID (der Token Ring Line) (EXCHID)<br />
|-<br />
|Gateway XID<br />
|Selbst würfeln, muss mit 056 beginnen<ref>Dieser Wert wird beim ersten Start per Autokonfiguration auf die AS/400-seitige Controllerbeschreibung übernommen.</ref><br />
|-<br />
|Gateway Network Name<br />
|Selbst würfeln, ggfs. den Namen aus dem Kontrollfeld ''Gemeinschaftsfunktionen'' benutzen<br />
|-<br />
|Gateway Network Qualifier<br />
|DSPNETA, Lokale Netzwerk-ID (LCLNETID)<br />
|}<br />
<br />
Die Charakteristik muss auf ''Peer (Node Type 2.1)'' gesetzt werden. Die ''SAP Address'' bleibt auf 4.<br />
<br />
=== Local 6.2 LUs ===<br />
[[File:Cfg-loclu.gif|thumb|right|183px|Lokale 6.2 LUs]]<br />
{|class="wikitable"<br />
!LU-Parameter<br />
!AS/400-Parameter<br />
|-<br />
|Name: PASSTHRU (wird im Kontrollfeld SNA•ps… der Clients benutzt)<br />
|&nbsp;<br />
|-<br />
|Network LU Name = Gateway Network Name aus der Partner-Konfiguration<br />
|&nbsp;<br />
|-<br />
|Network Qualifier<br />
|DSPNETA, Lokale Netzwerk-ID (LCLNETID)<br />
|}<br />
<br />
=== TPs ===<br />
[[File:Cfg-tp.gif|thumb|right|183px|Transaction Points]]<br />
Die eben definierte ''Local 6.2 LU'' muss markiert sein, damit ein neuer ''Transaction Point'' erstellt werden kann.<br />
* Name: * (Sternchen)<br />
* Network Name = DSPNETA, Lokale Netzwerk-ID der AS/400 (LCLNETID)<br />
<br />
Rest belassen.<br />
<br />
=== Remote 6.2 LUs ===<br />
[[File:Cfg-remlu.gif|thumb|right|183px|Ferne 6.2 LUs]]<br />
Der oben erstellte ''Partner'' muss markiert sein, damit eine zugehörige LU-Konfiguration erstellt werden kann.<br />
* Name = Name des ''Partner''s<br />
* Network LU name = Name des ''Partner''s<br />
* Network Qualifier = DSPNETA, Lokale Netzwerk-ID der AS/400 (LCLNETID)<br />
<br />
Rest belassen.<br />
<br />
=== Modes ===<br />
[[File:Cfg-mode-batchsc.gif|thumb|right|183px|Batch-Modusbeschreibung]]<br />
[[File:Cfg-mode-intersc.gif|thumb|right|183px|Interact-Modusbeschreibung]]<br />
Die oben erstellte ''Remote 6.2 LU'' muss markiert sein, damit eine zugehörige Mode-Konfiguration erstellt werden kann.<br />
<br />
Auf der AS/400 gibt es für deren eigenes Produkt ''Client Access'' eine passende Modusbeschreibung. In der Tabelle sind die passenden Werte eingetragen.<br />
<br />
{|class="wikitable"<br />
!Mode-Parameter<br />
!AS/400-Parameter in WRKMODD<br />
!QPCSUPP-Werte<br />
|-<br />
|Name<br />
|Name der Modusbeschreibung auf AS/400-Seite<br />
|QPCSUPP<br />
|-<br />
|Maximum Sessions<br />
|≤ Maximale Anzahl Sitzungen (MAXSSN)<br />
|64<br />
|-<br />
|Contention Winner<br />
|Lokal gesteuerte Sitzungen, sollte gleich den ''Maximum Sessions'' gehalten werden (LCLCTLSSN)<br />
|64<br />
|-<br />
|Prebound Sessions<br />
|= ''Contention Winner'' (PREESTSSN)<br />
|0<br />
|-<br />
|Send Pacing<br />
|Eingangsdosierwert (INPACING)<br />
|7<br />
|-<br />
|Receive Pacing<br />
|Ausgangsdosierwert (OUTPACING)<br />
|7<br />
|-<br />
|Maximum RU Upper<br />
|Max. Länge Anforderungseinheit (MAXLENRU). Falls dies auf *CALC gesetzt ist, 4096 in ''Maximum RU Upper'' eintragen.<br />
|4096<br />
|}<br />
<br />
Rest belassen.<br />
<br />
Es kann passieren, dass das Gateway nicht startet, weil der Speicher (auf der Karte) nicht ausreicht. Dann empfiehlt es sich, ein<br />
CRTDUPOBJ OBJ(QPCSUPP) FROMLIB(QSYS) OBJTYPE(*MODD) NEWOBJ(APLSNAPS)<br />
abzusetzen und mit ''wrkmodd'' anzupassen: MAXSSN und LCLCTLSSN auf z.&thinsp;B. 32 zu reduzieren. Dies muss logischerweise auch in der SNA ps-Config nachgezogen werden.<br />
<br />
== Aktivierung des Gateways ==<br />
Nachdem die Konfiguration gesichert wurde, wird diese mit dem Programm ''SNA•ps Admin'' der vorhandenen physikalischen Verbindung zugeordnet. Pro SNA-fähiger Verbindungskarte wird im eingeblendeten Fenster ''Network Gateway Status'' eine Zeile angezeigt. Die gewünschte Zeile wird markiert und danach im Menü ''Gateway'' mit ''Select configuration…'' der oben erstellten Konfiguration zugeordnet.<br /><br />
Im selben Menü wird empfohlen, über den Punkt ''Change Settings…''<br />
* dem Gateway einen schöneren Namen zuzuordnen und<br />
* alle Checkboxen bis auf ''Initially Log Line Trace'' unter ''Characteristics'' anzuknipsen.<br />
<br />
Danach kann im Menü ''Gateway'' mit ''Start Gateway'' die Gatewaysoftware gestartet werden.<br />
<br />
Es hat sich gezeigt, dass zumindest mit SNA•ps Version 1.1 das Ausprobieren von Konfigurationsinstellungen mit manuellem Stop und Start manchmal die Meldung provoziert, es wäre zu wenig Speicher vorhanden. Diese Aussage bezieht sich auf den lokalen Speicher auf der entsprechenden Netzwerkkarte. Anscheinend werden Ressourcen dort nicht zuverlässig überschrieben, nach einem Neustart des Rechners ist die Fehlermeldung weg.<br />
<br />
Ebenfalls im Menü ''Gateway'' kann nun mit ''Show Gateway'' eine Übersicht über die vorhandenen Ressourcen angezeigt werden. Ein Beispiel ist im zweiten Screenshot ab Artikelbeginn zu sehen.<br />
<br />
=== Screenshots ===<br />
<gallery mode="nolines"><br />
File:Stat-line.gif<br />
File:Stat-peer.gif<br />
File:Stat-loclu.gif<br />
File:Stat-tp.gif<br />
File:Stat-remlu.gif<br />
File:Stat-mode-snasvcmg.gif<br />
File:Stat-mode-batchsc.gif<br />
File:Stat-mode-intersc.gif<br />
File:Stat-sess-batchsc.gif<br />
File:Stat-sess-intersc.gif<br />
</gallery><br />
<br />
== Client-Konfiguration SNA•ps 5250 ==<br />
Im Kontrollfeld ''SNA•ps Access/5250'' kann in der ''Display Configuration'' auf ''Virtual Controller'' umgestellt werden. Der Controllername ist üblicherweise ''QPACTL01''.<br />
<br />
[[Datei:Dft-connsel.gif|right|thumb|Modaler Dialog zur Auswahl einer Standardsitzung]]<br />
Die Clientkonfiguration beschränkt sich auf die Auswahl der ''Default Connection'' im Menü ''Pref(erence)s''. Alternativ kann im Client die gewünschte Sitzung direkt konfiguriert werden (''Session'', ''Connection…'').<br />
<br />
Danach wird im Menü ''Session'' mit dem Punkt ''Connect'' die Verbindung zum vorab ausgewählten SNA-Gateway hergestellt. Nach einigen Sekunden wird der AS/400 Signon-Screen angezeigt.<br />
<br />
Nebenbei können dann auch noch weitere Parameter gesetzt werden: Größere Schriftart bei entsprechend großen Monitoren, alternative Tastenbelegungen für kleine Mac-Tastaturen (hier bietet sich der Zehnerblock an), usw. Die Einstellungen können in einem Verbindungsdokument gesichert werden. Beim Öffnen eines solchen Dokuments wird die Sitzung automatisch aufgebaut.<br />
<br />
Alle weiteren Einstellungen können je nach Gusto vorgenommen werden.<br />
<br />
== Client-Konfiguration SNA•ps Print ==<br />
Der Print-Client ist nur in der Paketversion 1.0 enthalten. Damit können Druckjobs flexibel gehandhabt werden.<br />
<br />
Im Kontrollfeld ''SNA•ps Access/5250'' muss in der ''Printer Configuration'', ''Printer Device List…'' ein Drucker konfiguriert werden. Dieser sollte auf der AS/400 nicht existieren, damit er mit den richtigen Parametern angelegt wird.<br />
<br />
Nach dem Start von ''SNA•ps Print'' wird nach einem Dateinamen für die nun neu angelegte Druckerverbindung gefragt. Dieses Dokument entsprechend sichern.<br />
<br />
Danach wird im Menü ''Session'' mit dem Punkt ''Connect'' die Verbindung zum vorab ausgewählten SNA-Gateway hergestellt. Die AS/400 legt eine Druckergerätedatei (*DEVD) und eine entsprechende Ausgabewarteschlange (*OUTQ) an. Alles was dort reingestellt wird, landet in der Druckroutine von SNA•ps Print.<br />
<br />
Es wird ein IBM 3812 Model 1 Drucker (SCS) emuliert.<br />
<br />
== Fehlerquellen ==<br />
* Die Benutzung von ''Trawl'' auf dem Gatewayrechner selbst bringt u.&thinsp;U. AppleTalk ins Schleudern, sodass das Gateway nicht mehr im Managertool auftaucht. Dann hilft nur ein Reboot des Gateway-Rechners.<br />
<br />
== Weblinks ==<br />
* Wikipedia (en):<br />
** [https://en.wikipedia.org/wiki/IBM_Systems_Network_Architecture IBM Systems Network Architecture]<br />
** [https://en.wikipedia.org/wiki/IBM_Advanced_Program-to-Program_Communication IBM Advanced Program-to-Program Communication]<br />
** [https://en.wikipedia.org/wiki/IBM_Advanced_Peer-to-Peer_Networking IBM Advanced Peer-to-Peer Networking]<br />
** [https://en.wikipedia.org/wiki/Synchronous_Data_Link_Control Synchronous Data Link Control]<br />
** [https://en.wikipedia.org/wiki/A/ROSE Apple Real-time Operating System Environment]<br />
** [https://en.wikipedia.org/wiki/Message_passing Message Passing]<br />
** [https://en.wikipedia.org/wiki/AppleTalk AppleTalk]<br />
** [https://en.wikipedia.org/wiki/LocalTalk LocalTalk]<br />
* [http://www.mactech.com/articles/develop/issue_04/coprocessor.html Inside The Macintosh Coprocessor Platform And A/ROSE]<br />
* [https://www.computerwoche.de/a/terminalemulation-bindet-apple-welt-an-as-400-mac-user-haben-direkten-zugriff-auf-as-400-daten,1128406 Terminalemulation bindet Apple-Welt an AS/400], Computerwoche 1993-06-11<br />
* [https://www.ibm.com/support/knowledgecenter/en/SSEQ5Y_5.9.0/com.ibm.pcomm.doc/books/html/admin_guide19.htm Administrator's Guide and Reference, SNA Client/Server Concepts], IBM<br />
* [https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.znetwork/znetwork_6.htm Introduction to networking on the mainframe], IBM<br />
* [https://web.archive.org/web/20181229140138/http://docwiki.cisco.com/wiki/IBM_Systems_Network_Architecture_Protocols IBM Systems Network Architecture Protocols], Cisco Docwiki (aus dem Archiv)<br />
<br />
== Fußnoten ==<br />
<references /><br />
<br />
[[Kategorie: AS/400]]<br />
[[Kategorie: Mac OS]]<br />
[[Kategorie: Netzwerk]]</div>PoChttps://kb.pocnet.net/index.php?title=VTAM_Cheat_Sheet&diff=2908VTAM Cheat Sheet2023-01-03T13:54:52Z<p>PoC: /* VTAM Display commands */ hint</p>
<hr />
<div>'''VTAM''' is a complex piece of Software. But basically it's just a bit like the UNIX ''inetd'' plus network stack, allowing remote entities to access locally defined services.<ref>Yes, this is a daring generalization. But we need to start ''somewhere'' with explanations.</ref><br />
<br />
This article tries to help remembering things. It should serve as a quick reference for handling tasks.<br />
<br />
== Configuration ==<br />
Usually, configuration is stored in a partitioned data set with the partial name ''vtamlst''. To derive it's name, look into ''sys1.proclib(vtam)'' to see the ''dd'' statements. Usually, it's<br />
* ''sys1.vtamlst'', or<br />
* ''sys1.local.vtamlst''.<br />
<br />
Notable members include:<br />
;atcstr*<br />
:Basic configuration. The ''CONFIG'' directive designates which ''atccon''-file to load as default.<br />
;atccon*<br />
:A comma separated list of ''major nodes'' to be handled at VTAM startup.<ref>''Major nodes'' can be activated manually, though.</ref><br />
<br />
Remaining members designate ''major nodes''. That is, textual definition files. This task is usually be done from a TSO session.<br />
<br />
=== Concepts of Major and Minor Nodes ===<br />
VTAM major nodes are roughly member names in the ''vtamlst'' PDS. The first non-comment line starts with a name, the literal ''VBUILD'', <code>TYPE=''node type''</code>, and optional parameters.<br />
<br />
Major node types:<br />
* ADJCP (Adjacent Control Point)<br />
* APPL (Application Program)<br />
* CA (Channel Attachment)<br />
* CDRSRC (Cross-Domain Resources)<br />
* CDRM (Cross-Domain Resource Manager)<br />
* XCA (External Communications Adapter)<br />
* LOCAL (Local SNA)<br />
* LUGROUP (Logical Unit Group)<br />
* MODEL (Model definition for dynamically created PU and LU; mostly for APPN)<br />
* SWNET (Switched, this is the definition of a "real" node)<br />
* DR (Dynamic Reconfiguration or Change)<br />
* ADSSJCP (Adjacent Control Point Table)<br />
* ADJCLUST (Adjacent cluster routing definitions)<br />
* APPNTOSA (APPN-to-subarea Class of Service mapping table)<br />
* SATOAPPN (Subarea-to-APPN Class of Service mapping table)<br />
* BNCOSMAP (Border node CoS mapping definitions)<br />
* NETSRVR (Network node server list)<br />
* GRPREFS (Generic resources preferences table)<br />
* SAMAP (Subarea mapping table)<br />
* SNSFILTR (Session awareness sense filter)<br />
<br />
== Administering VTAM ==<br />
This is done from a system console.<br />
<br />
VTAM is required by TCPIP, but TCPIP is smart enough to cope with VTAM being shut down and restarted without caring for TCPIP.<br />
<br />
=== VTAM Start commands ===<br />
VTAM is usually automatically started in the course of an IPL.<br />
<br />
{|class="wikitable"<br />
!Command<br />
!Comment<br />
|-<br />
|S NET<br />
|VTAM start with defaults<br />
|-<br />
|S NET,,,(LIST=00)<br />
|VTAM start with atcstr''00'' <br />
|}<br />
<br />
=== VTAM Display commands ===<br />
{|class="wikitable"<br />
!Command<br />
!Comment<br />
|-<br />
|D NET,APING,ID=''REMNODE'',LOGMODE=#INTER<br />
|Create an APPC "loopback" session<br />
|-<br />
|D NET,APPLS<br />
|Display VTAM applications status<br />
|-<br />
|D NET,BFRUSE<br />
|Display VTAM buffers in use<br />
|-<br />
|D NET,CDRMS<br />
|Display VTAM cross domains status<br />
|-<br />
|D NET,CDRSCS<br />
|Display VTAM cross domain resources<br />
|-<br />
|D NET,COS<br />
|Display VTAM cos table in use<br />
|-<br />
|D NET,GROUPS<br />
|Display VTAM groups status<br />
|-<br />
|D NET,MAJNODES<br />
|Display a list of '''active''' major nodes<br />
|-<br />
|D NET,NETSRVR<br />
|Display Network Node Server List, only valid if VTAM is in End-Node configuration.<br />
|-<br />
|D NET,ID=name<br />
|Display VTAM resource status<br />
|-<br />
|D NET,ID=*.name<br />
|Display VTAM resource status in any net<br />
|-<br />
|D NET,ID=ISTADJCP,E<br />
|Display dynamic list of adjacent CPs<br />
|-<br />
|D NET,RTPS<br />
|Display Rapid Transfer Protocol sessions. RTP is part of HPR.<br />
|-<br />
|D NET,TGPS<br />
|Display Transmission Groups<br />
|-<br />
|D NET,TOPO<br />
|Display APPN Topology<br />
|-<br />
|D NET,TRL<br />
|Display Transport Resource List<br />
|-<br />
|D NET,U,ID=userID<br />
|Display VTAM user ID status<br />
|-<br />
|D NET,VTAMOPTS<br />
|Display VTAM startup options currently set<br />
|}<br />
<br />
=== VTAM Vary commands ===<br />
{|class="wikitable"<br />
!Command<br />
!Comment<br />
|-<br />
|V NET,ACT,ID=name<br />
|Activate VTAM resource<br />
|-<br />
|V NET,INACT,ID=name<br />
|Inactivate VTAM resource<br />
|-<br />
|V NET,DRDS,ID=name<br />
|Activate VTAM dynamic reconfiguration<br />
|}<br />
<br />
=== VTAM Change commands ===<br />
{|class="wikitable"<br />
!Command<br />
!Comment<br />
|-<br />
|F NET,''VTAMOPTS'',''startoption=option''<br />
|Run-Time change VTAM configuration<br />
|-<br />
|F NET,VTAMOPTS,SORDER=APPNFRST<br>F NET,TRACE,ID=''resname'',TYPE=BUF<br>F NET,NOTRACE,ID=''resname'',TYPE=BUF<br />
|valgni="top"|Examples<br />
|}<br />
<br />
=== VTAM Halt commands ===<br />
VTAM won't halt QUICK when application programs are active. Stop with the given commands.<br />
* NFS-Client<ref>If anyone knows how to prevent the NFS-Client from starting at startup, please drop [mailto:poc@pocnet.net me] a note.</ref><br />
P NFSC<br />
* TSO<br />
P TSO<br />
<br />
{|class="wikitable"<br />
!Command<br />
!Comment<br />
|-<br />
|Z NET,CANCEL<br />
|VTAM abnormal termination command<br />
|-<br />
|Z NET,QUICK<br />
|VTAM somewhat faster termination command<br />
|-<br />
|Z NET<br />
|VTAM normal termination command<br />
|}<br />
<br />
== Literature ==<br />
* IBM z/OS Basic Skills Information Center: [https://www.ibm.com/docs/en/zos-basic-skills?topic=networking-zos ''Networking on z/OS''] <br />
* IBM Redbook: ''P/390, R/390, S/390 Integrated Server: OS/390 New User′s Cookbook'', document number [https://ibmdocs.pocnet.net/SG24-4757-01.pdf SG24-4757-01]<br />
<br />
== Footnotes ==<br />
<references /><br />
<br />
[[Category: MVS]]</div>PoChttps://kb.pocnet.net/index.php?title=Benutzer:PoC/Apple_IIgs_Netzwerk-Boot&diff=2907Benutzer:PoC/Apple IIgs Netzwerk-Boot2022-12-30T22:08:38Z<p>PoC: Ein paar Links zu Anfang</p>
<hr />
<div>== Weblinks ==<br />
* [https://archive.org/details/AppleShare_Server_3.0_Administrators_Guide AppleShare Server 3.0 Administrators Guide], PDF Page 90ff<br />
* [https://peterwong.net/blog/apple-iigs-network-netatalk/ Apple IIgs Network: Netatalk], Peter Wong Blog<br />
<br />
[[Kategorie: Apple II]]</div>PoChttps://kb.pocnet.net/index.php?title=Benutzer:PoC&diff=2906Benutzer:PoC2022-12-30T22:04:07Z<p>PoC: /* Was später mal wird */ +Link</p>
<hr />
<div>== Begriffserklärung ==<br />
PoC steht in meinem Falle für die genauere Beschreibung meines Vornamens: '''P'''atrik '''o'''hne '''C''' - man schreibt mich Patrik.<br />
<br />
== Links ==<br />
* [http://www.pocnet.net/ Offizielle Heimseite von mir]<br />
<br />
== Von mir verfaßte bzw. überarbeitete Artikel ==<br />
Können [[Spezial:Beiträge/PoC|hier]] nachgelesen werden. Ansonsten finden sich hier auch weniger computerzentrierte Artikel.<br />
<br />
* [[Benutzer:PoC/Ursachen von Brummstörungen in Röhrenverstärkern]]<br />
* [[Benutzer:PoC/Debian-Live Netzbootserver]]<br />
<br />
== Was später mal wird ==<br />
* [[Benutzer:PoC/Solarheizung]]<br />
* [[Benutzer:PoC/DCF77-Nixie-Röhrenuhr]]<br />
* [[Benutzer:PoC/Stromversorgungsautarkie]]<br />
* [[Benutzer:PoC/Mausefalle-Archive mit modernen Mitteln verfügbar machen]]<br />
* [[Benutzer:PoC/Schlüssel und Zertifikat für AppleMail bereitstellen]]<br />
* [[Benutzer:PoC/PostScript von LaserWriter 6 konvertieren]]<br />
* [[Benutzer:PoC/Apple IIgs Netzwerk-Boot]]</div>PoChttps://kb.pocnet.net/index.php?title=Linux_von_BIOS-_auf_UEFI-Boot_umstellen&diff=2905Linux von BIOS- auf UEFI-Boot umstellen2022-11-28T13:42:15Z<p>PoC: /* Mögliche Fehler */ Typos</p>
<hr />
<div>Ohne zu wissen, was es mit EFI auf sich hat, ist das '''Umstellen von Linux von BIOS- auf EFI-Boot''' auf echter Serverhardware (die meistens minutenlang in der internen Firmware rumhängt) zeitraubend und frustrierend. In Kürze Erklärung und Wichtiges:<br />
<br />
== Grundlagen ==<br />
(U)EFI ((Unified) Extensible Firmware Interface) ist mit neuerer Hardware unvermeidbar. Eigentlich ist das Thema sehr einfach: Es gibt keinen binären Bootblock mehr, sondern eine kleine FAT32-Partition zu Beginn der Boot-Disk (ggfs. HW-RAID-Array). Die Bootloader der verschiedenen Betriebssysteme erzeugen eine Verzeichnisstruktur, in welcher dann das eigentliche Startprogramm hinterlegt wird. Die Firmware sammelt beim Systemstart eine Liste der gefundenen ausführbaren Binaries (PE32+ executable) und bietet diese dann zum Start an (bzw. der Standardeintrag wird gestartet).<br />
<br />
== Fallstricke ==<br />
* Ohne Repartitionieren geht es nicht. Da die Umstellung auf EFI durch einem Hardwaretausch mit anschließender Kopie der vorhandenen Installation durchgeführt wird, ist das aber kein Beinbruch.<br />
* Der initiale Boot (CD, ISO-Image, PXE, USB-Stick, usw.) muss zwingend im EFI-Modus mit einem dementsprechend EFI-fähigen Bootmedium durchgeführt werden. Das Debian-Live-Image von Debian 8 oder älter ist nicht geeignet! Erst ab 9 gibt es EFI-Support, z.&thinsp;B. [http://cdimage.debian.org/debian-cd/9.6.0-live/amd64/iso-hybrid/debian-live-9.6.0-amd64-xfce.iso debian-live-9.6.0-amd64-xfce.iso]. Ohne Boot im EFI-Modus sind die EFI-Hooks in der Firmware unsichtbar und Grub-EFI wird mit Fehlern um sich werfen.<br />
* Falls das alte BIOS-Grub-Paket mit <code>--purge</code> gelöscht wird, ist '''unbedingt''' danach ein<br />
grub-install dummy<br />
update-grub<br />
abzusetzen, da das Purge des BIOS-Paketes auch die Konfiguration und weitere Dateien löscht. Nach einem Reboot gibt's ansonsten die Grub-Kommandozeile.<br />
<br />
== Checkliste ==<br />
* Neues System vorbereiten (FW-Updates, BIOS-Settings, usw.),<br />
* Bootmedium vorbereiten (siehe oben),<br />
* Boot via EFI-Bootmenü von diesem Medium,<br />
* Ggfs. manuelle Netzwerkkonfiguration,<br />
* Nachinstallation von benötigten Systemkomponenten (gdisk, mdadm, dosfstools),<br />
* Vorbereiten der Platten für das OS:<br />
** Partitionieren (''gdisk''), dabei (eine) z.&thinsp;B. 100&thinsp;MB große EFI-Partition(en) anlegen, Typ EF00,<ref>Tatsächlich benötigt werden vom Grub-Loader einige 100&thinsp;KBytes.</ref><br />
** Ggfs. Erzeugen der gewünschten Arrays mit ''mdadm'',<br />
** Dateisysteme erzeugen, dabei die EFI-Partition(en) mit einem FAT32-Dateisystem versehen, z.&thinsp;B.: <code>mkfs.fat -F32 /dev/sda1</code>,<br />
** Mounten des OS-Dateisystems nach z.&thinsp;B. ''/mnt'', <code>cd /mnt</code>,<br />
** Kopieren der Installation vom Quellsystem, wie gehabt mit z.&thinsp;B. <code>ssh ''srcsys'' "dump -0a -b 256 -f - /dev/sda1" |restore -r -b 256 -f -</code>,<br />
** Vorbereitungen für ''chroot'': <code>mount -o bind /dev dev/</code>,<br />
* <code>chroot /mnt</code>,<br />
* Nachmounten von Kernel-Pseudo-Dateisystemen: <code>mount -t proc none /proc; mount -t sysfs none /sys; mount -t devpts none /dev/pts</code>,<br />
* Anpassen der ''/etc/fstab'', dabei Eintragen der EFI-Partition(en),<br />
* Anpassen der ''/etc/fstab'', dabei Eintragen von ''efivars'':<br />
none /sys/firmware/efi/efivars efivarfs defaults 0 0<br />
* Mounten der EFI-Partition(en),<br />
* Nachinstallation von benötigten Systemkomponenten (gdisk, mdadm, dosfstools),<br />
* Ggfs. schreiben der RAID-Konfiguration mit <code>/usr/share/mdadm/mkconf > /etc/mdadm/mdadm.conf; update-initramfs -u</code>,<br />
* Austauschen von Grub: <code>apt-get install grub-efi-amd64 grub-efi-amd64-bin</code>,<br />
* Löschen von altem Grub-PC-Kram: <code>dpkg -P grub-pc grub-pc-bin</code>,<br />
* Prüfen, ob ''/etc/default/grub'' existiert und falls nicht, nochmal vom Backup kopieren.<br />
<br />
Grub-EFI erfordert keine Platte mehr als Parameter beim beim Grub-Install. Statt dessen wird als (leider benötigter Parameter) ''dummy'' übergeben.<br />
grub-install dummy<br />
<br />
* Raus aus der chroot: <code>exit</code>,<br />
* Unmounten: <code>umount boot/efi* dev proc sys; cd ..; umount mnt</code>.<br />
<br />
Nach einem Reboot muss die Installation dann wieder sauber hochkommen. Weitere Schritte wie Netzwerkkonfigurationsanpassungen an die neue Hardware sind nicht beschrieben.<br />
<br />
=== Mögliche Fehler ===<br />
grub-install: warning: EFI variables are not supported on this system.<br />
<br />
Dieser Fehler kann zum einen bedeuten, dass das System selbst im BIOS-Modus gestartet wurde. Allerdings scheint es ab Debian 11 notwendig zu sein, einen weiteren Mountpoint zu setzen:<br />
<br />
none /sys/firmware/efi/efivars efivarfs defaults 0 0<br />
<br />
Damit funktioniert dann auch ein <code>grub-install</code> fehlerfrei.<br />
<br />
=== Redundanz ===<br />
Beim Booten kann dann statt einem möglicherweise wechselnden Gerät, eine Boot-Konfiguration aus dem genannten Verzeichnis eines beliebigen Gerätes gestartet werden. Vorbei sind die Tage, in denen in einem Software-RAID die erste Platte ausfällt, die zweite Platte dann an die erste Stelle rückt, der Bootblock ist aber nicht auf die erste Platte konfiguriert, sondern entweder überhaupt nicht<ref>Schlampiger Admin…</ref> oder das BIOS kommt mit der neuen BIOS-ID (0x80 statt 0x81) nicht zurecht und verweigert den Boot.<br />
<br />
EFI hat allerdings eine konzeptionelle Schwachstelle: Die Einfachhheit eine ''/boot''-Partition per Software-RAID zu spiegeln ist nicht vorgesehen. Man kann sich was basteln über ''mdadm'' mit nicht persistentem Superblock (damit keine Daten überschrieben werden), aber das ist letztlich alles Gebastel.<br /><br />
Am Einfachsten ist es, manuell die Verzeichnisstruktur auf die zuvor manuell identisch partitionierten und in ''/boot/efi2'', ''/boot/efi3'', usw. gemounteten FAT32-Partitionen zu kopieren.<br />
<br />
Für Debian muss eine Datei angelegt und als ausführbar markiert werden: ''/etc/grub.d/42_update-hook'':<br />
#!/bin/sh<br />
# Dirty hack: If there are multiple FA32-mountpoints in /boot/efi, sync<br />
# contents manually to provide poor man's redundancy.<br />
if mount -t vfat |awk '{print $3}' |grep -q '^/boot/efi$'; then<br />
cat /dev/null > /var/log/update-grub.log<br />
for MP in `mount -t vfat |awk '{print $3}' |grep -v '^/boot/efi$'`; do<br />
rsync -av --delete /boot/efi/ ${MP}/ >> /var/log/update-grub.log<br />
done<br />
else<br />
echo "No EFI Mount Point detected." > /var/log/update-grub.log<br />
fi<br />
<br />
# --EOF--<br />
<br />
Bei jedem Aufruf, der die Grub-Konfiguration neu erzeugt, wird somit auch die Struktur kopiert. Das beinhaltet auch Updates von Kernel und Grub selbst. Fire and forget.<br />
<br />
== Weblinks ==<br />
* [https://outflux.net/blog/archives/2018/04/19/uefi-booting-and-raid1/ UEFI booting and RAID1]<br />
* [https://www.heise.de/newsticker/meldung/Was-Linux-Anwender-ueber-UEFI-wissen-muessen-4204725.html Was Linux-Anwender über UEFI wissen müssen]<br />
* [https://packages.debian.org/stable/bootcd Run your system from cd without need for disks]<ref>Ob das EFI kompatible Images herstellt, ist derzeit nicht bekannt.</ref><br />
* [https://wiki.debian.org/EFIStub …it is possible to load the kernel directly, without any additional bootloader]<br />
<br />
== Fußnoten ==<br />
<references /><br />
<br />
[[Kategorie: Linux]]</div>PoChttps://kb.pocnet.net/index.php?title=Linux_von_BIOS-_auf_UEFI-Boot_umstellen&diff=2904Linux von BIOS- auf UEFI-Boot umstellen2022-11-28T13:41:52Z<p>PoC: /* Checkliste */ +Efivarfs</p>
<hr />
<div>Ohne zu wissen, was es mit EFI auf sich hat, ist das '''Umstellen von Linux von BIOS- auf EFI-Boot''' auf echter Serverhardware (die meistens minutenlang in der internen Firmware rumhängt) zeitraubend und frustrierend. In Kürze Erklärung und Wichtiges:<br />
<br />
== Grundlagen ==<br />
(U)EFI ((Unified) Extensible Firmware Interface) ist mit neuerer Hardware unvermeidbar. Eigentlich ist das Thema sehr einfach: Es gibt keinen binären Bootblock mehr, sondern eine kleine FAT32-Partition zu Beginn der Boot-Disk (ggfs. HW-RAID-Array). Die Bootloader der verschiedenen Betriebssysteme erzeugen eine Verzeichnisstruktur, in welcher dann das eigentliche Startprogramm hinterlegt wird. Die Firmware sammelt beim Systemstart eine Liste der gefundenen ausführbaren Binaries (PE32+ executable) und bietet diese dann zum Start an (bzw. der Standardeintrag wird gestartet).<br />
<br />
== Fallstricke ==<br />
* Ohne Repartitionieren geht es nicht. Da die Umstellung auf EFI durch einem Hardwaretausch mit anschließender Kopie der vorhandenen Installation durchgeführt wird, ist das aber kein Beinbruch.<br />
* Der initiale Boot (CD, ISO-Image, PXE, USB-Stick, usw.) muss zwingend im EFI-Modus mit einem dementsprechend EFI-fähigen Bootmedium durchgeführt werden. Das Debian-Live-Image von Debian 8 oder älter ist nicht geeignet! Erst ab 9 gibt es EFI-Support, z.&thinsp;B. [http://cdimage.debian.org/debian-cd/9.6.0-live/amd64/iso-hybrid/debian-live-9.6.0-amd64-xfce.iso debian-live-9.6.0-amd64-xfce.iso]. Ohne Boot im EFI-Modus sind die EFI-Hooks in der Firmware unsichtbar und Grub-EFI wird mit Fehlern um sich werfen.<br />
* Falls das alte BIOS-Grub-Paket mit <code>--purge</code> gelöscht wird, ist '''unbedingt''' danach ein<br />
grub-install dummy<br />
update-grub<br />
abzusetzen, da das Purge des BIOS-Paketes auch die Konfiguration und weitere Dateien löscht. Nach einem Reboot gibt's ansonsten die Grub-Kommandozeile.<br />
<br />
== Checkliste ==<br />
* Neues System vorbereiten (FW-Updates, BIOS-Settings, usw.),<br />
* Bootmedium vorbereiten (siehe oben),<br />
* Boot via EFI-Bootmenü von diesem Medium,<br />
* Ggfs. manuelle Netzwerkkonfiguration,<br />
* Nachinstallation von benötigten Systemkomponenten (gdisk, mdadm, dosfstools),<br />
* Vorbereiten der Platten für das OS:<br />
** Partitionieren (''gdisk''), dabei (eine) z.&thinsp;B. 100&thinsp;MB große EFI-Partition(en) anlegen, Typ EF00,<ref>Tatsächlich benötigt werden vom Grub-Loader einige 100&thinsp;KBytes.</ref><br />
** Ggfs. Erzeugen der gewünschten Arrays mit ''mdadm'',<br />
** Dateisysteme erzeugen, dabei die EFI-Partition(en) mit einem FAT32-Dateisystem versehen, z.&thinsp;B.: <code>mkfs.fat -F32 /dev/sda1</code>,<br />
** Mounten des OS-Dateisystems nach z.&thinsp;B. ''/mnt'', <code>cd /mnt</code>,<br />
** Kopieren der Installation vom Quellsystem, wie gehabt mit z.&thinsp;B. <code>ssh ''srcsys'' "dump -0a -b 256 -f - /dev/sda1" |restore -r -b 256 -f -</code>,<br />
** Vorbereitungen für ''chroot'': <code>mount -o bind /dev dev/</code>,<br />
* <code>chroot /mnt</code>,<br />
* Nachmounten von Kernel-Pseudo-Dateisystemen: <code>mount -t proc none /proc; mount -t sysfs none /sys; mount -t devpts none /dev/pts</code>,<br />
* Anpassen der ''/etc/fstab'', dabei Eintragen der EFI-Partition(en),<br />
* Anpassen der ''/etc/fstab'', dabei Eintragen von ''efivars'':<br />
none /sys/firmware/efi/efivars efivarfs defaults 0 0<br />
* Mounten der EFI-Partition(en),<br />
* Nachinstallation von benötigten Systemkomponenten (gdisk, mdadm, dosfstools),<br />
* Ggfs. schreiben der RAID-Konfiguration mit <code>/usr/share/mdadm/mkconf > /etc/mdadm/mdadm.conf; update-initramfs -u</code>,<br />
* Austauschen von Grub: <code>apt-get install grub-efi-amd64 grub-efi-amd64-bin</code>,<br />
* Löschen von altem Grub-PC-Kram: <code>dpkg -P grub-pc grub-pc-bin</code>,<br />
* Prüfen, ob ''/etc/default/grub'' existiert und falls nicht, nochmal vom Backup kopieren.<br />
<br />
Grub-EFI erfordert keine Platte mehr als Parameter beim beim Grub-Install. Statt dessen wird als (leider benötigter Parameter) ''dummy'' übergeben.<br />
grub-install dummy<br />
<br />
* Raus aus der chroot: <code>exit</code>,<br />
* Unmounten: <code>umount boot/efi* dev proc sys; cd ..; umount mnt</code>.<br />
<br />
Nach einem Reboot muss die Installation dann wieder sauber hochkommen. Weitere Schritte wie Netzwerkkonfigurationsanpassungen an die neue Hardware sind nicht beschrieben.<br />
<br />
=== Mögliche Fehler ===<br />
grub-install: warning: EFI variables are not supported on this system.<br />
<br />
Dieser Fehler kann zum einen bedeuten, dass das System selbst im BIOS-Modus gestartet wurde. Allerdings scheint es ab Debian 11 notwendig zu sein, einen weiteren Mountpoint zu setzen:<br />
<br />
none /sys/firmware/efi/efivars efivars default 0 0<br />
<br />
Damit funktioniert dann auch ein <code>grub-install</code> fehlerfrei.<br />
<br />
=== Redundanz ===<br />
Beim Booten kann dann statt einem möglicherweise wechselnden Gerät, eine Boot-Konfiguration aus dem genannten Verzeichnis eines beliebigen Gerätes gestartet werden. Vorbei sind die Tage, in denen in einem Software-RAID die erste Platte ausfällt, die zweite Platte dann an die erste Stelle rückt, der Bootblock ist aber nicht auf die erste Platte konfiguriert, sondern entweder überhaupt nicht<ref>Schlampiger Admin…</ref> oder das BIOS kommt mit der neuen BIOS-ID (0x80 statt 0x81) nicht zurecht und verweigert den Boot.<br />
<br />
EFI hat allerdings eine konzeptionelle Schwachstelle: Die Einfachhheit eine ''/boot''-Partition per Software-RAID zu spiegeln ist nicht vorgesehen. Man kann sich was basteln über ''mdadm'' mit nicht persistentem Superblock (damit keine Daten überschrieben werden), aber das ist letztlich alles Gebastel.<br /><br />
Am Einfachsten ist es, manuell die Verzeichnisstruktur auf die zuvor manuell identisch partitionierten und in ''/boot/efi2'', ''/boot/efi3'', usw. gemounteten FAT32-Partitionen zu kopieren.<br />
<br />
Für Debian muss eine Datei angelegt und als ausführbar markiert werden: ''/etc/grub.d/42_update-hook'':<br />
#!/bin/sh<br />
# Dirty hack: If there are multiple FA32-mountpoints in /boot/efi, sync<br />
# contents manually to provide poor man's redundancy.<br />
if mount -t vfat |awk '{print $3}' |grep -q '^/boot/efi$'; then<br />
cat /dev/null > /var/log/update-grub.log<br />
for MP in `mount -t vfat |awk '{print $3}' |grep -v '^/boot/efi$'`; do<br />
rsync -av --delete /boot/efi/ ${MP}/ >> /var/log/update-grub.log<br />
done<br />
else<br />
echo "No EFI Mount Point detected." > /var/log/update-grub.log<br />
fi<br />
<br />
# --EOF--<br />
<br />
Bei jedem Aufruf, der die Grub-Konfiguration neu erzeugt, wird somit auch die Struktur kopiert. Das beinhaltet auch Updates von Kernel und Grub selbst. Fire and forget.<br />
<br />
== Weblinks ==<br />
* [https://outflux.net/blog/archives/2018/04/19/uefi-booting-and-raid1/ UEFI booting and RAID1]<br />
* [https://www.heise.de/newsticker/meldung/Was-Linux-Anwender-ueber-UEFI-wissen-muessen-4204725.html Was Linux-Anwender über UEFI wissen müssen]<br />
* [https://packages.debian.org/stable/bootcd Run your system from cd without need for disks]<ref>Ob das EFI kompatible Images herstellt, ist derzeit nicht bekannt.</ref><br />
* [https://wiki.debian.org/EFIStub …it is possible to load the kernel directly, without any additional bootloader]<br />
<br />
== Fußnoten ==<br />
<references /><br />
<br />
[[Kategorie: Linux]]</div>PoChttps://kb.pocnet.net/index.php?title=Linux_von_BIOS-_auf_UEFI-Boot_umstellen&diff=2903Linux von BIOS- auf UEFI-Boot umstellen2022-11-13T19:33:11Z<p>PoC: /* Checkliste */ Efivars, siehe https://bbs.archlinux.org/viewtopic.php?id=249546</p>
<hr />
<div>Ohne zu wissen, was es mit EFI auf sich hat, ist das '''Umstellen von Linux von BIOS- auf EFI-Boot''' auf echter Serverhardware (die meistens minutenlang in der internen Firmware rumhängt) zeitraubend und frustrierend. In Kürze Erklärung und Wichtiges:<br />
<br />
== Grundlagen ==<br />
(U)EFI ((Unified) Extensible Firmware Interface) ist mit neuerer Hardware unvermeidbar. Eigentlich ist das Thema sehr einfach: Es gibt keinen binären Bootblock mehr, sondern eine kleine FAT32-Partition zu Beginn der Boot-Disk (ggfs. HW-RAID-Array). Die Bootloader der verschiedenen Betriebssysteme erzeugen eine Verzeichnisstruktur, in welcher dann das eigentliche Startprogramm hinterlegt wird. Die Firmware sammelt beim Systemstart eine Liste der gefundenen ausführbaren Binaries (PE32+ executable) und bietet diese dann zum Start an (bzw. der Standardeintrag wird gestartet).<br />
<br />
== Fallstricke ==<br />
* Ohne Repartitionieren geht es nicht. Da die Umstellung auf EFI durch einem Hardwaretausch mit anschließender Kopie der vorhandenen Installation durchgeführt wird, ist das aber kein Beinbruch.<br />
* Der initiale Boot (CD, ISO-Image, PXE, USB-Stick, usw.) muss zwingend im EFI-Modus mit einem dementsprechend EFI-fähigen Bootmedium durchgeführt werden. Das Debian-Live-Image von Debian 8 oder älter ist nicht geeignet! Erst ab 9 gibt es EFI-Support, z.&thinsp;B. [http://cdimage.debian.org/debian-cd/9.6.0-live/amd64/iso-hybrid/debian-live-9.6.0-amd64-xfce.iso debian-live-9.6.0-amd64-xfce.iso]. Ohne Boot im EFI-Modus sind die EFI-Hooks in der Firmware unsichtbar und Grub-EFI wird mit Fehlern um sich werfen.<br />
* Falls das alte BIOS-Grub-Paket mit <code>--purge</code> gelöscht wird, ist '''unbedingt''' danach ein<br />
grub-install dummy<br />
update-grub<br />
abzusetzen, da das Purge des BIOS-Paketes auch die Konfiguration und weitere Dateien löscht. Nach einem Reboot gibt's ansonsten die Grub-Kommandozeile.<br />
<br />
== Checkliste ==<br />
* Neues System vorbereiten (FW-Updates, BIOS-Settings, usw.),<br />
* Bootmedium vorbereiten (siehe oben),<br />
* Boot via EFI-Bootmenü von diesem Medium,<br />
* Ggfs. manuelle Netzwerkkonfiguration,<br />
* Nachinstallation von benötigten Systemkomponenten (gdisk, mdadm, dosfstools),<br />
* Vorbereiten der Platten für das OS:<br />
** Partitionieren (''gdisk''), dabei (eine) z.&thinsp;B. 100&thinsp;MB große EFI-Partition(en) anlegen, Typ EF00,<ref>Tatsächlich benötigt werden vom Grub-Loader einige 100&thinsp;KBytes.</ref><br />
** Ggfs. Erzeugen der gewünschten Arrays mit ''mdadm'',<br />
** Dateisysteme erzeugen, dabei die EFI-Partition(en) mit einem FAT32-Dateisystem versehen, z.&thinsp;B.: <code>mkfs.fat -F32 /dev/sda1</code>,<br />
** Mounten des OS-Dateisystems nach z.&thinsp;B. ''/mnt'', <code>cd /mnt</code>,<br />
** Kopieren der Installation vom Quellsystem, wie gehabt mit z.&thinsp;B. <code>ssh ''srcsys'' "dump -0a -b 256 -f - /dev/sda1" |restore -r -b 256 -f -</code>,<br />
** Vorbereitungen für ''chroot'': <code>mount -o bind /dev dev/</code>,<br />
* <code>chroot /mnt</code>,<br />
* Nachmounten von Kernel-Pseudo-Dateisystemen: <code>mount -t proc none /proc; mount -t sysfs none /sys; mount -t devpts none /dev/pts</code>,<br />
* Anpassen der ''/etc/fstab'', dabei Eintragen der EFI-Partition(en),<br />
* Mounten der EFI-Partition(en),<br />
* Nachinstallation von benötigten Systemkomponenten (gdisk, mdadm, dosfstools),<br />
* Ggfs. schreiben der RAID-Konfiguration mit <code>/usr/share/mdadm/mkconf > /etc/mdadm/mdadm.conf; update-initramfs -u</code>,<br />
* Austauschen von Grub: <code>apt-get install grub-efi-amd64 grub-efi-amd64-bin</code>,<br />
* Löschen von altem Grub-PC-Kram: <code>dpkg -P grub-pc grub-pc-bin</code>,<br />
* Prüfen, ob ''/etc/default/grub'' existiert und falls nicht, nochmal vom Backup kopieren.<br />
<br />
Grub-EFI erfordert keine Platte mehr als Parameter beim beim Grub-Install. Statt dessen wird als (leider benötigter Parameter) ''dummy'' übergeben.<br />
grub-install dummy<br />
<br />
* Raus aus der chroot: <code>exit</code>,<br />
* Unmounten: <code>umount boot/efi* dev proc sys; cd ..; umount mnt</code>.<br />
<br />
Nach einem Reboot muss die Installation dann wieder sauber hochkommen. Weitere Schritte wie Netzwerkkonfigurationsanpassungen an die neue Hardware sind nicht beschrieben.<br />
<br />
=== Mögliche Fehler ===<br />
grub-install: warning: EFI variables are not supported on this system.<br />
<br />
Dieser Fehler kann zum einen bedeuten, dass das System selbst im BIOS-Modus gestartet wurde. Allerdings scheint es ab Debian 11 notwendig zu sein, einen weiteren Mountpoint zu setzen:<br />
<br />
none /sys/firmware/efi/efivars efivars default 0 0<br />
<br />
Damit funktioniert dann auch ein <code>grub-install</code> fehlerfrei.<br />
<br />
=== Redundanz ===<br />
Beim Booten kann dann statt einem möglicherweise wechselnden Gerät, eine Boot-Konfiguration aus dem genannten Verzeichnis eines beliebigen Gerätes gestartet werden. Vorbei sind die Tage, in denen in einem Software-RAID die erste Platte ausfällt, die zweite Platte dann an die erste Stelle rückt, der Bootblock ist aber nicht auf die erste Platte konfiguriert, sondern entweder überhaupt nicht<ref>Schlampiger Admin…</ref> oder das BIOS kommt mit der neuen BIOS-ID (0x80 statt 0x81) nicht zurecht und verweigert den Boot.<br />
<br />
EFI hat allerdings eine konzeptionelle Schwachstelle: Die Einfachhheit eine ''/boot''-Partition per Software-RAID zu spiegeln ist nicht vorgesehen. Man kann sich was basteln über ''mdadm'' mit nicht persistentem Superblock (damit keine Daten überschrieben werden), aber das ist letztlich alles Gebastel.<br /><br />
Am Einfachsten ist es, manuell die Verzeichnisstruktur auf die zuvor manuell identisch partitionierten und in ''/boot/efi2'', ''/boot/efi3'', usw. gemounteten FAT32-Partitionen zu kopieren.<br />
<br />
Für Debian muss eine Datei angelegt und als ausführbar markiert werden: ''/etc/grub.d/42_update-hook'':<br />
#!/bin/sh<br />
# Dirty hack: If there are multiple FA32-mountpoints in /boot/efi, sync<br />
# contents manually to provide poor man's redundancy.<br />
if mount -t vfat |awk '{print $3}' |grep -q '^/boot/efi$'; then<br />
cat /dev/null > /var/log/update-grub.log<br />
for MP in `mount -t vfat |awk '{print $3}' |grep -v '^/boot/efi$'`; do<br />
rsync -av --delete /boot/efi/ ${MP}/ >> /var/log/update-grub.log<br />
done<br />
else<br />
echo "No EFI Mount Point detected." > /var/log/update-grub.log<br />
fi<br />
<br />
# --EOF--<br />
<br />
Bei jedem Aufruf, der die Grub-Konfiguration neu erzeugt, wird somit auch die Struktur kopiert. Das beinhaltet auch Updates von Kernel und Grub selbst. Fire and forget.<br />
<br />
== Weblinks ==<br />
* [https://outflux.net/blog/archives/2018/04/19/uefi-booting-and-raid1/ UEFI booting and RAID1]<br />
* [https://www.heise.de/newsticker/meldung/Was-Linux-Anwender-ueber-UEFI-wissen-muessen-4204725.html Was Linux-Anwender über UEFI wissen müssen]<br />
* [https://packages.debian.org/stable/bootcd Run your system from cd without need for disks]<ref>Ob das EFI kompatible Images herstellt, ist derzeit nicht bekannt.</ref><br />
* [https://wiki.debian.org/EFIStub …it is possible to load the kernel directly, without any additional bootloader]<br />
<br />
== Fußnoten ==<br />
<references /><br />
<br />
[[Kategorie: Linux]]</div>PoChttps://kb.pocnet.net/index.php?title=Debian-Squeeze-Migration_32-_nach_64-Bit&diff=2902Debian-Squeeze-Migration 32- nach 64-Bit2022-11-12T23:09:40Z<p>PoC: /* Installation von Apache2/kbd schlägt fehl */ Typo</p>
<hr />
<div>Das Debian-Paketsystem kennt bis maximal Version 6 (Squeeze) keinen Weg zu einer sauberen Architekturmigration einer bestehenden Installation. Nichts anderes ist ist eine Umstellung von i386 auf amd64. Ab Debian 7 (Wheezy) kennt das Paketsystem die Möglichkeit verschiedener Architekturen auf einem System zu beherbergen. Beizeiten gibt es dann auch eine entsprechende Aktualisierung dieses Artikels. Deutlich: '''Nicht mit Debian 7 oder neuer versuchen, dort sind die Vorgehensweisen anders!'''<br />
<br />
Das hier vorgestellte Prinzip ist einfach, aber nicht unbedingt schön:<br />
* Installation eines 64-Bit-Kernels,<br />
* Erstellen eines minimalen 64-Bit-chroot-Systems,<br />
* Überschreiben der zentralen Binärdateien mittels dieses Minisystems,<br />
* Reinstallation aller installierten Pakete mit der zugehörigen 64-Bit-Variante.<br />
<br />
Eine Neuinstallation ist andererseits recht aufwendig, wenn diese umfangreiche Konfigurationsanpassungen, Benutzer, usw. durchlebt hat.<br />
<br />
Dieses Upgrade setzt Kenntnisse mit ''apt-get'', ''dpkg'' und allgemeinen systemadministrativen Aufgaben voraus. Im Laufe des Vorganges ergeben sich sehr individuelle Konstellationen von Abhängigkeiten, die im Rahmen dieser Kurzanleitung nicht abgedeckt werden können.<br />
<br />
Dieses Update benötigt Zugang zur Maschinenkonsole. Eine Ferninstallation über ''ssh'' oder ''telnet'' ist nicht durchführbar. Die beschriebenen Schritte wurden mit Debian Lenny und Squeeze getestet.<br />
<br />
== Vorbereitungen ==<br />
=== Benötigtes Prozessorfeature prüfen ===<br />
grep -q '^flags.* lm ' /proc/cpuinfo && echo "Can 64-Bit"<br />
Wenn diese Ausgabe erfolgt, kann das System auf 64-Bit aktualisiert werden. Ansonsten nicht.<br />
<br />
=== Dokumentation der Plattenpartitionen ===<br />
Zu einem späteren Zeitpunkt wäre wichtig zu wissen, auf welcher Partition welches Dateisystem ruht.<br />
df -h<br />
gibt eine Liste der Partitionen und ihrer Mountpoints, sowie der Platzbelegung aus. Diese sollten wir in einer Datei auf einem anderen System zugänglich aufbewahren oder ausgedruckt auf einem Blatt Papier zur Hand haben.<br />
<br />
== Installation eines passenden 64-Bit-Kernels ==<br />
In der Regel genügt es, das zugehörige Kernel-Metapaket zu installieren:<br />
apt-get install linux-image-2.6-amd64<br />
<br />
Nach der Installation und dem obligatorischen Reboot ist darauf zu achten, dass der Kernel auch wirklich gestartet wird. In der Standardkonfiguration von Grub werden die Kernelvarianten alphabetisch aufgelistet, sodass ''amd64'' immer vor ''ix86'' liegt.<br />
<br />
Nach dem Reboot läuft aller Kernelcode bereits im 64-Bit-Modus. Nun müssen noch die Programme ausgetauscht werden, damit diese ebenfalls in diesem Modus laufen.<br />
<br />
== Erstellen eines 64-Bit-Minisystems ==<br />
In diesem Beispiel wird das System in ''/chroot64'' installiert. Jeder andere Platz ist ebenfalls möglich, muss im Laufe dieser Anleitung allerdings entsprechend berücksichtigt werden.<br />
mkdir /chroot64<br />
apt-get install debootstrap<br />
debootstrap --arch amd64 squeeze /chroot64 <nowiki>http://ftp.de.debian.org/debian</nowiki><br />
<br />
Dieses Minisystem besteht ausschließlich aus 64-Bit-Komponenten. Statt Squeeze sollte die bereits installierte Distribution benutzt werden.<br />
<br />
In diesem Minisystem müssen nun noch ein paar weitere Pakete installiert werden:<br />
chroot /chroot64<br />
apt-get install file bzip2 openssh-client tnftp<br />
<CTRL-D><br />
<br />
=== Anlegen einer Liste der Binärprogramme des Minisystems ===<br />
Damit das eigentliche Hauptsystem (auf schmutzige Weise) von 32- auf 64-Bit hochgezogen werden kann, brauchen wir eine Liste der ausführbaren Binärdateien des Minisystems. Nur diese Programme und Libraries sind relevant und müssen ausgetauscht werden:<br />
cd /chroot64<br />
find . -depth |while read f; do<br />
if file -L "$f" |fgrep -q ELF; then<br />
echo "$f" >> /tmp/binaries.txt<br />
fi<br />
done<br />
echo "./etc/ld.so.cache" >> /tmp/binaries.txt<br />
<br />
Das Hinzufügen des ''ld.so.cache'' ist unabdingbar! Der Cache ist zwar kein ausführbares Programm, wird aber vom dynamischen Linker (''ld.so'') benötigt.<br />
<br />
=== Angleichen des 32-Bit-Systems an das Minisystem ===<br />
Damit das alte System aus Sicht der Konfiguration dem Minisystem so ähnlich wie möglich wird, sollten nun alle Pakete im Minisystem auch im alten 32-Bit-System vorhanden sein. Diese werden also nun nachinstalliert:<br />
chroot /chroot64<br />
dpkg --get-selections |awk '{print $1}' > /tmp/minipackages.txt<br />
<CTRL-D><br />
apt-get update<br />
apt-get install `cat /chroot64/tmp/minipackages.txt`<br />
<br />
=== Starten von externem Linux-Medium ===<br />
Hierbei ist es ziemlich egal, auf welche Weise das System gestartet wird (CD, USB-Stick, PXE-Boot, …). Wichtig ist nur, dass<br />
* das derzeit installierte System nicht läuft, da im Folgeschritt zentrale Dateien ausgetauscht werden müssen,<br />
* das zu startende Linux eine 64-Bit-Installation ist.<br />
<br />
Das Debian-Projekt bietet zu diesem Zweck [http://cdimage.debian.org/cdimage/release/current-live/amd64/ Liveimages] an. Das Rescue-Image reicht für unsere Zwecke aus.<br />
<br />
Die Partitionen des installierten Systems müssen nach dem Startvorgang zugänglich gemacht werden. Dabei ist die weiter oben angelegte Partitionsliste eine große Hilfe und vermeidet unnötiges Raten, welche Partition nun gleich wieder was war.<br />
mount /dev/sda3 /mnt<br />
mount /dev/sda1 /mnt/boot<br />
…<br />
<br />
Alle Partitionen mit Binärprogrammen müssen gemountet werden. Also zum Beispiel ein separates ''/usr''-Dateisystem, aber nicht unbedingt ''/home''. Falls Unsicherheit herrscht, besser alle mounten.<br />
<br />
== Überschreiben des 32-Bit-Basissystems ==<br />
Damit das System später per Paketinstallation auf 64-Bit umgestellt werden kann, müssen vorher die zentralen Binärdateien ausgetauscht werden. Dies geschieht anhand der weiter oben angelegten ''Liste-der-Binärdateien'':<br />
cd /mnt/chroot64<br />
cpio -pVdu /mnt < /mnt/tmp/binaries.txt<br />
<br />
Da 32- und 64-Bit-Libraries koexistieren können, gibt es zwei Pfade, die wir an dieser Stelle auf einen zeigen lassen, damit das System auch starten kann:<br />
cd ..<br />
ln -s /lib lib64<br />
<br />
Nun räumen wir auf und starten neu:<br />
cd ..<br />
umount /mnt/boot /mnt<br />
reboot<br />
<br />
=== Start des neu gebauten 64-Bit-Systems ===<br />
Nun kann das bereits vorher installierte, nun minimal auf 64-Bit gezogene System gestartet werden. Der Großteil des Systems besteht noch aus 32-Bit-Komponenten. Das sorgt bei einem Standardstartvorgang für eine erhebliche Menge an Fehlermeldungen. Diese können ignoriert werden. Alternativ kann in Grub auch der Punkt "(rescue)" ausgewählt werden, was den Startvorgang etwas beschleunigt als auch die Menge der Fehlermeldungen reduziert.<br />
<br />
Letztendlich können wir uns einloggen und an dieser Stelle weitermachen.<br />
<br />
== Reinstallation aller Pakete ==<br />
Damit das komplette System aus 64-Bit-Komponenten besteht, müssen alle Pakete neu installiert werden. Dieser Vorgang ist wie oben gesagt sehr individuell. An dieser Stelle können wir nur auf die häufigsten Fehler und ihre Behebung eingehen.<br />
<br />
Laut der Apt-Datenbank ist das System derzeit in einem nicht validen Zustand: ''Apt'' sieht anhand ''uname -m'', dass das System 64-bittig ist, aber alle vorhandenen Pakete in ihrer 32-Bit-Variante installiert sind (i386). Diesen Zustand müssen wir nun auf möglichst saubere Weise ändern.<br />
apt-get update<br />
apt-get install -f<br />
<br />
Nun werden alle Pakete zum Austausch in ihrer amd64-Variante heruntergeladen und installiert. Dabei können wiederum Fehlermeldungen auftreten, zum Beispiel von Postinstall-Scripten, welche versuchen, Programme aufzurufen, die derzeit noch in der 32-Bit-Variante installiert sind.<br />
<br />
Hier ist nun systemadministrative Kreativität gefragt. Einige der häufiger auftretenden Fehler wären:<br />
<br />
=== Libc6 wird nicht automatisch aktualisiert ===<br />
Internal Error, Could not perform immediate configuration (2) on libc6<br />
E: Could not perform immediate configuration on 'libc6'.<br />
Please see man 5 apt.conf under APT::Immediate-Configure for details.<br />
<br />
Das Libc6-Paket wurde zwar heruntergeladen, aber nicht ausgepackt, weil das Original eine andere Architektur aufweist. Hier müssen wir diese Apt-Vorsichtsmaßnahme (durch manuelle Installation) umgehen:<br />
dpkg -i /var/cache/apt/archives/libc6*deb<br />
Alternativ:<br />
apt-get dist-upgrade -o APT::Immediate-Configure=0<br />
<br />
Weiter mit erneutem Aufruf von <br />
apt-get install -f<br />
<br />
=== Librarykollisionen ===<br />
Die derzeit eingesetzte Version des dynamischen Loaders (ld.so) unterstützt keine 32- und 64-Bit Libraries im gleichen Verzeichnis. Warnungen ähnlich wie wie:<br />
ldconfig: libraries libz.so.1.2.3.0 and libz.so.1.2.3.3 in directory /usr/lib have same soname but different type.<br />
bedeuten, dass geprüft werden muss, welches die 32-Bit-Variante ist, die üblicherweise gelöscht werden kann (da wir ja auf 64-Bit aktualisieren).<br />
'''cd /usr/lib'''<br />
'''ls -l libz.so*'''<br />
lrwxrwxrwx 1 root root 15 Dec 30 21:25 libz.so -> libz.so.1.2.3.4<br />
lrwxrwxrwx 1 root root 15 Dec 30 21:25 libz.so.1 -> libz.so.1.2.3.4<br />
-rw-r--r-- 1 root root 93936 Dec 28 20:10 libz.so.1.2.3.4<br />
-rw-r--r-- 1 root root 93936 Jun 18 11:14 libz.so.1.2.3.0<br />
'''file libz.so.1.2.*'''<br />
libz.so.1.2.3.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped<br />
libz.so.1.2.3.4: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped<br />
'''rm libz.so.1.2.3.0'''<br />
'''ldconfig'''<br />
'''apt-get -f install'''<br />
<br />
Dieser Fehler tritt dann auf, wenn sich die Versionen des alten 32-Bit-Systems und des neuen 64-Bit-Systems unterscheiden, quasi gleichzeitig ein ''dist-upgrade'' auf eine neue Debian-Version durchgeführt wird. Das ist nicht empfohlen.<br />
<br />
=== Installation von libperl schlägt fehl ===<br />
Die Installation von ''perl-base'' schlägt fehl, weil die ''libperl.so.5.10.1'' ebenfalls im Paket ''libc5.10'' enthalten ist. Wir können diese aber getrost überschreiben:<br />
dpkg --force-overwrite -i /var/cache/apt/archives/perl-base_*<br />
apt-get -f install<br />
<br />
=== Debsums schlägt fehl ===<br />
Falls Fehler auftreten, weil das md5-Modul von Perl nicht funktioniert (weil es tatsächlich ein Binärmodul ist), dann kann auch dieses manuell und forciert installiert werden. Je nach dem kann dies zu Konflikten wegen bereits aus anderen (älteren) Paketen vorhandenen Dateien führen. Daher empfiehlt es sich, ein Überschreiben zuzulassen:<br />
dpkg -i --force-overwrite /var/cache/apt/archives/perl*<br />
apt-get -f install<br />
<br />
=== Reinstallation von ''doc-base'' schlägt fehl ===<br />
Dieses Paket benutzt ndbm Datenbankdateien (''files.db'' und ''status.db''), welche aber achitekturspezifisch sind. Die Austauschprozedur 32→64-Bit kann mit dieser Situation nicht umgehen. Das ist aber nicht weiter schlimm, ein simples Löschen dieser Dateien forciert ein Neuanlegen.<br />
rm -f /var/lib/doc-base/info/*.db<br />
apt-get -f install<br />
<br />
=== Installation von Apache2/kbd schlägt fehl ===<br />
Die sehr unübersichtliche Ausgabe zeigt gleich zwei Fehler:<br />
* ''Apache2'' kann nicht installiert werden, weil Apt sich nicht klar ist, ob nun ''mpm-worker'' oder ''mpm-prefork'' benutzt werden soll,<br />
* Die Konsole-Tools können nicht installiert werden, weil Apt sich nicht klar ist, ob nun ''kbd'' oder die ''console-tools'' installiert werden sollen. Letzteres kann Apt nicht auflösen, weil keine ''libconsole'' installiert werden soll. Abhilfe mit:<br />
apt-get install apache2-mpm-prefork console-tools libconsole<br />
apt-get -f install<br />
<br />
=== Konfiguration von Qmail schlägt fehl ===<br />
Die Konfiguration von Qmail bricht mit dem Fehler 127 ab. Ursache ist, dass das Programm ''svc'' von den Daemontools nicht im Suchpfad gefunden werden kann. Abhilfe mit:<br />
export PATH=/usr/local/bin:$PATH<br />
apt-get -f install<br />
<br />
=== Hilfspakete ===<br />
Manche Postinstall-Scripte benötigen ''menu'' and ''pyhon''. Wenn im Rahmen des Prozesses Nachrichten über ''update-menus failed'' auftreten, dann ist das hierauf zurückzuführen.<br />
<br />
Manuell forcierte Installation dieser Pakete hilft auch hier:<br />
dpkg -i /var/cache/apt/archives/menu* /var/cache/apt/archives/python*<br />
apt-get -f install<br />
<br />
Die gleiche Problematik (nur für Python) trifft auch bei Fehlermeldungen über ''python-apt'' und ''python-xapian'' zu.<br />
apt-get install python2.5 python2.5-minimal<br />
apt-get -f install<br />
<br />
=== Manuelle Reinstallation verbleibender 32-Bit Pakete ===<br />
Wenn ein <code>apt-get install -f </code> keine weiteren Aufgaben ausführt, ist das System soweit migriert. Trotzdem bleiben manchmal einige Pakete als 32-Bit-Variante erhalten. Falls Apt in der Statistik sagt, es würde noch ein Paket nicht aktualisiert worden, muss noch ein<br />
apt-get dist-upgrade<br />
<br />
Eine Auflistung der verbleibenden Pakete erhalten wir mit diesem Befehl:<br />
dpkg-query -W -f '${Package} ${Architecture}\n' |awk '/i386$/ {print $1}'<br />
<br />
Ein schöner Nebeneffekt dieser Methode ist, dass hierbei auch Leichen zutage gefördert werden. Also Pakete, die vor langer Zeit installiert wurden, einige Upgrades überlebt haben, aber inzwischen nicht mehr im Apt zu finden sind und deswegen nicht aktualisiert werden konnten. Diese können jetzt deinstalliert werden, bzw. durch ein funktional äquivalentes Paket ersetzt werden (wie z.&thinsp;B. ''pine'' → ''alpine'').<br />
<br />
Ein automatisches Upgrade aller restlichen 32-Bit-Pakete ergibt sich aus dem obigen Kommando zur Listenerzeugung:<br />
apt-get install `dpkg-query -W -f '${Package} ${Architecture}\n' |awk '/i386$/ {print $1}'`<br />
<br />
Alternativ kann die Liste Paket für Paket abgearbeitet werden. Dieser Vorgang ist langsamer, aber weniger fehleranfällig: Abhängigkeiten werden pro Paket separat behandelt.<br />
for p in `dpkg-query -W -f '${Package} ${Architecture}\n' |awk '/i386$/ {print $1}'`; do<br />
apt-get -y install $p<br />
done<br />
<br />
Wenn hierbei nichts mehr passiert, werden keine 32-Bit-Pakete mehr gefunden. Als letzter Schritt sollte sicherheitshalber nochmal die ''initrd'' neu gebaut werden:<br />
update-initramfs -u<br />
<br />
Ein finaler Reboot startet dann das System in seiner 64-Bit-Variante.<br />
<br />
=== Nacharbeiten ===<br />
Da sich die Prozessorarchitektur geändert hat, haben sich teilweise auch (binäre) Datenformate geändert.<br />
<br />
* INN startet nicht mehr mit der Logmeldung <code>/var/lib/news/history cant dbminit SERVER Numerical argument out of domain</code>. Die Binärdatenbank mit folgendem Kommando neu erzeugen (als User ''news''):<br />
/usr/lib/news/bin/makehistory -oir<br />
* MTA prüfen (Aliasdatei, usw.).<br />
* Netatalk prüfen (hat bei Squeeze keinen Ärger gemacht).<br />
* RRD-Dateien prüfen (''mailgraph'', o.&thinsp;Ä.)<br />
<br />
Ebenso müssen nachträglich hinzugefügte Kernelmodule neu erzeugt werden, wie z.&thinsp;B. Open-vm-tools, AFS, dahdi, Iscsitarget, usw.<br />
<br />
== Weblinks ==<br />
* [http://wiki.debian.org/Migrate32To64Bit Debian-Wiki, Migrate32To64Bit]<br />
* [http://blog.zugschlus.de/archives/972-How-to-amd64-an-i386-Debian-installation-with-multiarch.html Unüberprüfte Vorgehensweise für Wheezy]<br />
<br />
[[Kategorie:Linux]]</div>PoChttps://kb.pocnet.net/index.php?title=Cisco_IOS_Konfigurationsgrundlagen&diff=2901Cisco IOS Konfigurationsgrundlagen2022-11-04T09:11:05Z<p>PoC: /* Struktur */ +do</p>
<hr />
<div>Dieser Artikel soll eine Kurzeinweisung in die '''Konfigurationsgrundlagen''' von '''Cisco IOS''' geben. Die vorgestellten Praktiken gelten allerdings nur für hinreichend neue Releases (11 oder neuer).<br />
<br />
== Erstinbetriebnahme ==<br />
Die Grundkonfiguration erfolgt seriell mit den Einstellungen 9600-N-8-1. Die Konsolenschnittstelle ist bis auf wenige Ausnahmen als RJ-45-Steckverbindung ausgeführt. Dazu wird das passende Konfigurationskabel benötigt.<br />
<br />
Ein Router ohne Konfiguration bootet das IOS vom Flashspeicher und versucht auf seine Konfiguration zuzugreifen. Gibt es diese nicht, fragt IOS nach, ob man den Konfigurationsassistenten starten möchte.<br />
<br />
Erscheint stattdessen eine Loginaufforderung, so muss zuerst eine sogenannte ''Password Recovery'' durchgeführt werden, siehe Abschnitt [[#Weblinks|Weblinks]].<br />
<br />
== Struktur ==<br />
Außer am Loginprompt kann der Benutzer jederzeit ein Fragezeichen eingeben, um eine kontextabhängige Hilfe zum jeweiligen Modus zu erhalten. Die Hilfefunktion berücksichtigt auch Kommandos mit mehreren Parametern, sodass der Benutzer jederzeit Kenntnis über die erforderliche Syntax erhalten kann.<br />
<br />
Mit Hilfe der Tabulatortaste können begonnene Kommandos vervollständigt werden, sofern die eingegebene Buchstabenfolge eindeutig ist.<br />
<br />
Die grundlegende Struktur sieht aus wie folgt:<br />
* Prompt<br>→ Login<br />
** Unprivilegierte Kommandozeile<br>→ ''enable''<br />
*** Privilegierte Kommandozeile<br>→ ''configure''<br />
**** Konfigurationsmodus<br>→ ''interface …''<br />
***** Subkontext (Interface, Line, usw.)<br />
***** ← ''exit''<br />
**** ← ''end''<br />
*** ← ''disable''<br />
** ← ''logout''<br />
<br />
Am ''Loginprompt'' muss sich der Benutzer vor dem Zugriff auf die Kommandozeile (Cisco-Sprech: exec) erst authentisieren. Je nach Konfiguration kann der Zugriff auf Adressebene restriktiert sein oder der Login ist benutzerlos (nur mit Passwort) möglich. Ebenso ist es möglich, dass auf der seriellen Konsole keine Authentifizierung konfiguriert wurde, während Zugriffe per Telnet/ssh authentisiert werden müssen. Der Prompt endet in einem Größerzeichen.<br /><br />
Auf dieser Ebene können Benutzer nichtadministrative Aufgaben erledigen, wie z.&thinsp;B. die momentane Exec-Sitzung in eine PPP-Sitzung umwandeln, auf der Kommandozeile mittels ''Ping'' und ''Traceroute'' Netzwerkdiagnosen durchführen oder sich per Telnet/ssh weiterverbinden.<br /><br />
Aus diesem Modus kann der Benutzer mit ''exit'' oder ''logout'' die Sitzung schließen und für einen erneuten Login bereit machen.<br />
<br />
In den ''privilegierten Modus'' gelangt man mit dem ''Enable-Passwort''. Dieses ist in der Konfiguration entweder im Klartext oder als MD5-Hash hinterlegt (<code>enable password</code> bzw. <code>enable secret</code>. Je nach Konfiguration muss kein Enable-Passwort eingegeben werden, um direkt vom Loginprompt in den privilegierten Modus zu gelangen. Der Prompt endet in einer Raute.<br /><br />
Die zwei häufigsten Gründe, in den privilegierten Modus zu wechseln, ist die Ausgabe der Konfiguration oder die Absicht, die Konfiguration zu ändern. Ebenso ist es möglich, mit ''reload'' das Gerät erneut zu starten.<br /><br />
Aus diesem Modus kann der Benutzer mit ''disable'' wieder in den nichtprivilegierten Modus wechseln, oder mit ''exit'', ''logout'', usw. schließen und für einen erneuten Login bereit machen.<br />
<br />
Im privilegierten Modus kann in den Konfigurationsmodus gewechselt werden. Das Kommando erwartet als Parameter eine Konfigurationsquelle. In den allermeisten Fällen ist das ''terminal'', also per Kommandozeileneingabe. Der Prompt ändert sich auf ''(configure)'' vor der Raute.<br /><br />
In diesem Modus können generische Parameter der Konfiguration zur Laufzeit geändert werden.<br /><br />
Aus diesem Modus kann der Benutzer mit ''end'' oder ''exit'' wieder in den ''privilegierten Modus'' wechseln.<br />
<br />
Im Subkontext-Konfigurationsmodus werden spezifische Parameter konfiguriert. Bei Betrachten einer bestehenden Konfiguration ist dies an einer Einrückung der Parameter erkennbar.<br />
<br /><br />
Aus diesem Modus kann der Benutzer mit ''exit'' wieder in den globalen Konfigurationsmodus zurückwechseln oder mit ''end'' zurück in den ''privilegierten Modus''.<br />
<br />
Aus dem Konfigurationsmodus heraus kann kurzzeitig durch ein vorangestelltes <code>do</code> in den ''normalen Modus'' umgeschaltet werden, z.&thinsp;B. um direkt ein <code>write</code> der Konfiguration auf den Permanentspeicher zu forcieren.<br />
<br />
=== Konfiguration ===<br />
Zu beachten ist: Manche Parameter werden bei Änderung überschrieben (z.&thinsp;B. das ''enable-secret'', da es nur eines geben kann). Andere Parameter werden wie eine Liste ergänzt (z.&thinsp;B. ''ntp server''). Das Entfernen von Konfigurationseinstellungen kann in den allermeisten Fällen durch wiederholen der exakten Konfigurationszeile mit einem vorangestellten ''no'' erreicht werden.<br />
<br />
IOS-Geräte haben zwei Konfigurationen:<br />
* ''Running-Config'' ist die derzeit aktive Konfiguration.<br />
* ''Startup-Config'' ist die gespeicherte Konfiguration für den nächsten Bootvorgang.<br />
<br />
Die Ausgabe erfolgt mit ''show'', also<br />
show startup-config<br />
bzw.<br />
show running-config<br />
<br />
Die Konfiguration kann im privilegierten Modus gespeichert werden:<br />
write memory<br />
<br />
Hat man einen Fehler gemacht, kann durch einen Reboot des Gerätes die gespeicherte Konfiguration reaktiviert werden.<br />
reload<br />
<br />
Vor einem Eigentümerwechsel des Gerätes, ist es zweckmäßig, die Konfiguration vorher zu löschen und den Auslieferungszustand damit herzustellen:<br />
erase nvram<br />
<br />
Die Konfiguration der Geräte ist Text. Beim Bootvorgang des Gerätes wird die gespeicherte Konfiguration abgearbeitet, als würde sie per Hand nach und nach eingegeben. Eine Sicherung der Konfiguration kann daher problemlos mit einem Texteditor angefertigt werden.<br />
<br />
== Minimale Konfiguration für Remotezugriff ==<br />
Je nachdem ist es etwas umständlich, ein zurückgesetztes oder neues IOS-Gerät nur seriell konfigurieren zu können. Eine minimale Konfiguration für den Zugriff via Telnet sieht beispielsweise wie folgt aus:<br />
interface VLan1<br />
ip address 192.168.196.100 255.255.255.0<br />
no shutdown<br />
!<br />
ip route 0.0.0.0 0.0.0.0 Vlan1 192.168.196.1<br />
!<br />
enable secret blahblubb<br />
!<br />
line vty 0 4<br />
password blahblubb<br />
!<br />
<br />
Als Interface muss ein Layer-3-Interface genommen werden. Bei einigen Modellen ist ein Switchmodul (mit Layer-2-Interfaces) eingebaut, welches hintendran zu einem Layer-3-VLan-Interface zusammengefasst wird. Falsch machen kann man eigentlich nichts. Wenn man versucht, einem Switchport eine IP-Adresse zu verpassen, antwortet IOS mit einer entsprechenden Meldung auf der Konsole. Eine Übersicht über die vorhandenen Schnittstellen mit ihren Kurznamen liefert ein<br />
show interface description<br />
<br />
== Siehe auch ==<br />
* [[Vlans einfach erklärt]]<br />
<br />
== Weblinks ==<br />
* [http://www.cisco.com/en/US/docs/ios/fundamentals/configuration/guide/12_4/cf_12_4_book.html Cisco.com: Cisco IOS Configuration Fundamentals Configuration Guide] (engl.)<br />
* [http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/products_tech_note09186a00801746e6.shtml Cisco.com: Password Recovery Procedures] (engl.)<br />
<br />
[[Kategorie:Cisco]]</div>PoChttps://kb.pocnet.net/index.php?title=DNS-Flush_unter_OS_X&diff=2899DNS-Flush unter OS X2022-11-03T22:33:04Z<p>PoC: Neuer</p>
<hr />
<div>Leeren des DNS-Caches („Flushing“) unter Apple (Mac) OS X<br />
<br />
== Mac OS X 10.4 Tiger ==<br />
<br />
sudo lookupd -flushcache<br />
<br />
== Mac OS 10.5 Leopard ==<br />
<br />
sudo dscacheutil -flushcache<br />
<br />
'''Achtung''': Dieser Befehl löscht nicht nur den DNS-Cache, sondern alle Caches der ''Directory Services'', d.&nbsp;h. auch Benutzer-, Gruppen- und Management-Daten!<br />
<br />
== Mac OS X 10.6 Snow Leopard, OS X 10.7 Lion, 10.8 Mountain Lion, 10.9 Mavericks ==<br />
sudo killall -HUP mDNSResponder<br />
<br />
Der mDNSResponder ist jetzt für jegliches DNS zuständig.<br />
<br />
s. a. [http://support.apple.com/kb/HT5343 OS X: How to reset the DNS cache]<br />
<br />
== OS X 10.10 Yosemite, 10.10.0 bis inklusive 10.10.3 ==<br />
<br />
sudo discoveryutil udnsflushcache<br />
sudo discoveryutil mdnsflushcache<br />
<br />
„udnsflushcache“ löscht Unicast-Caches, „mdnsflushcache“ dagegen Multicast-Caches.<br />
<br />
== OS X 10.10 Yosemite, ab einschließlich 10.10.4 ==<br />
Dies funktioniert mit allen neueren Versionen bis einschließlich 11.7 und vermutlich auch darüber.<br />
<br />
sudo killall -HUP mDNSResponder<br />
<br />
[[Kategorie:Software]]<br />
[[Kategorie:Mac OS X]]<br />
[[Kategorie:DNS]]</div>PoChttps://kb.pocnet.net/index.php?title=AS/400-Konfiguration_f%C3%BCr_ausgehende_SMTP-Verbindungen&diff=2898AS/400-Konfiguration für ausgehende SMTP-Verbindungen2022-10-25T21:14:48Z<p>PoC: /* Test */ +Logging</p>
<hr />
<div>Ausgehende SMTP-Mail ist ein immer wieder in vielen Forenbeiträgen zu findendes Thema. Das liegt sicherlich mithin an der nicht so ganz intuitiven Konfiguration vor allem des Routingeintrags im Systemverzeichnis. Ausgehend von V4R5 soll hier Schritt für Schritt gezeigt werden, was notwendig ist, um lokal per SMTP Mails zu versenden.<br />
<br />
== Voraussetzungen ==<br />
* Das Subsystem für Qsnads muss laufen,<br />
STRSBS QSNADS<br />
* das Mail-Server-Framework muss gestartet sein (QMSF).<br />
STRMSF<br />
<br />
== Absenderadressen definieren ==<br />
Jeder lokale Benutzer (der Mails versenden können soll) braucht eine Absenderadresse gemäß [https://tools.ietf.org/html/rfc5322#section-3.4 RFC 5322]. Diese wird im lokalen Verzeichnis (das ist '''nicht''' das Benutzerprofil) hinterlegt.<br />
<br />
Mit <code>wrkdire</code> kann das Verzeichnis bearbeitet werden. Für jeden Eintrag wird mit ''F19'' eine '''gültige''' SMTP-Adresse hinterlegt. Diese wird als Absenderadresse verwendet. Das heisst, je nach Konfiguration der umgebenden Mailsysteme in Sachen Relaying, SPF usw., werden Absender mit externen Domains zurückgewiesen.<br /><br />
Auf der sicheren Seite ist, wer als Domain-Part den im DNS für die AS/400 vermerkten Domainnamen verwendet. Somit würden auch Bounces ankommen.<br />
<br />
== Mailrouting konfigurieren ==<br />
Für die Zustellung von Mails wird in diesem Beispiel angenommen, dass der Mailversand über einen Relayhost läuft, der Mails ohne Authentisierung annimmt und dann weiterleitet, mit den Dingen, die man heutzutage so haben möchte wie z.&thinsp;B. TLS.<br />
* Konfiguration SMTP-Dienst:<br />
CHGSMTPA AUTOSTART(*YES) RTYMIN(3 5) RTYHOUR(3 20) MAILROUTER('mailrelay.example.com') FIREWALL(*NO) JOURNAL(*YES) ALLMAILMSF(*YES) PCTRTGCHR(*NO)<br />
* Anlegen eines Routingeintrages im Systemverzeichnis:<br />
ADDDIRE USRID(INTERNET GATEWAY) USRD('Allow SNDDST to send INTERNET Mail') SYSNAME(INTERNET) MSFSRVLVL(*USRIDX) PREFADR(NETUSRID *IBM ATCONTXT)<br />
* Konfiguration der Verteilungsattribute:<br />
CHGDSTA SMTPRTE(INTERNET GATEWAY)<br />
<br />
Die am wenigsten intuitiven Parameter sind jene für den Verzeichniseintrag des Gateway-Benutzers:<br />
* Der Parameter ''atcontxt'' referenziert einen vorgefertigten Konfigurationseintrag des AnyMail/400 Mail Server Frameworks für die ''Art der Adresse'',<br />
* der Parameter ''netusrid'' referenziert den ''Feldnamen'', in welchem die ''Adresse'' zu finden ist, ''*IBM'' gibt lediglich an, dass der Eintrag von IBM stammt.<br />
<br />
Details hierzu finden sich in der Dokumentation zum Mail Server Framework, hauptsächlich für Programmierer interessant.<br />
<br />
== Test ==<br />
SNDDST TYPE(*LMSG) TOINTNET(('poc@pocnet.net')) DSTD('No Description') LONGMSG('Das ist der Message Body') SUBJECT('Betreff')<br />
<br />
Logeinträge für das Mail Server Framework einsehen:<br />
DSPJRN JRN(QZMF)<br />
<br />
== Siehe auch ==<br />
* [[AS/400 SNADS Konfiguration]]<br />
<br />
== Weblinks ==<br />
* [https://www.experts-exchange.com/questions/27291090/Configure-SMTP-on-iSeries-w-v4r5-aand-or-v5r1-to-use-SNDDST.html Configure SMTP on iSeries w/ v4r5 and or v5r1 to use SNDDST] – Experts Exchange (lang!)<br />
* [https://www.ibm.com/support/knowledgecenter/ssw_i5_54/rzair/rzair.pdf Networking E-mail] – IBM<br />
* [https://www.ibm.com/support/knowledgecenter/en/ssw_i5_54/apis/off3a.htm AnyMail/400 Mail Server Framework APIs] – IBM<br />
* [http://www.code400.com/forum/forum/tips-techniques-tools-announcements/tips-for-the-iseries-as400/2175-send-email-qtmmsendmail Send email - QtmmSendMail API Examples] – Code400<br />
<br />
[[Kategorie: AS/400]]</div>PoChttps://kb.pocnet.net/index.php?title=Benutzer:PoC/Inbetriebnahme_Power7&diff=2897Benutzer:PoC/Inbetriebnahme Power72022-10-20T15:28:41Z<p>PoC: Mehr Schritte</p>
<hr />
<div># Seriellport (ASMI) mit Cisco-Kabel, 19200-N-8-1<br />
# Login: admin/admin<br />
# IP-Konfiguration<br />
# https://www.ibm.com/docs/en/power7?topic=ivm-installing-vios-power-systems-server</div>PoChttps://kb.pocnet.net/index.php?title=Benutzer:PoC/Inbetriebnahme_Power7&diff=2896Benutzer:PoC/Inbetriebnahme Power72022-10-20T10:26:44Z<p>PoC: neu</p>
<hr />
<div># Seriellport (ASMI) mit Cisco-Kabel, 19200-N-8-1<br />
# Login: admin/admin</div>PoChttps://kb.pocnet.net/index.php?title=Systemd_bei_Debian_loswerden&diff=2895Systemd bei Debian loswerden2022-10-17T08:15:53Z<p>PoC: /* Gründe */ Typo</p>
<hr />
<div>'''Debian Jessie''' (und neuer) bringt per Default ein neues Startsystem, mit: Systemd. Nach sorgfältiger Recherche und Abwägen des Für und Wider habe ich mich dazu entschlossen, meine Debian-Installationen ohne '''Systemd''' zu betreiben, sondern auf die nach wie vor unterstützte traditionelle Sysv-Umgebung zu setzen. Bei den Betrachtungen ist wichtig, dass es hier nicht um Desktopsysteme geht, sondern um Serverinstallationen.<br />
<br />
== Gründe ==<br />
Achtung, dies ist meine subjektive Betrachtungsweise!<br />
<br />
* Systemd ist unübersichtlich, weil Systemd alles abdecken möchte, was derzeit von bekannten und gut funktionierenden Subsystemen abgedeckt wird:<br />
** ''Init'' für Runlevelmanagement und Startvorgang,<br />
** ''Udev'' für dynamische ''/dev''-Nodes und Netzwerkinterfaces,<br />
** Ergänzung/Ablöse von ''(x)inetd'' zwecks Nachstarten von Prozessen,<br />
** evtl. weiteres, was mir bisher nicht negativ aufgefallen ist.<br />
<br />
Welche eigentlich netten und relevanten Features verlieren die Installationen durch den Verzicht?<br />
* Den beeindruckend schnellen Startvorgang, u.&thinsp;A. durch Parallelisierung von Daemonstarts,<br />
* Automatische Prozessisolation durch die Integration von ''cgroups'' in den Startvorgang.<br />
<br />
Was gewinnt man durch den Verzicht?<br />
* Eine bekannte, verlässliche und durch jahrelange Erfahrung gestützte Systemumgebung, die alte Hasen im Schlaf und zeitgleichem Vollsuff beherrschen; ein nicht zu unterschätzender Punkt für Serveradministratoren,<br />
* deutlich näher dran an ''[https://en.wikipedia.org/wiki/Everything_is_a_file everything is a file]'',<br />
* erprobtes Logging im ASCII-Format mit allen Vorteilen wie z.&thinsp;B. ''grep''.<br />
<br />
== Vorgehensweise ==<br />
apt-get install sysvinit-core systemd-shim bootlogd systemd-sysv-<br />
reboot<br />
<br />
Danach:<br />
apt-get autoremove --purge systemd systemd-shim<br />
<br />
Fertig.<br />
<br />
Beim letzten ''apt-get''-Aufruf sollte geprüft werden, ob eventuell weitere Pakete deinstalliert werden, welche ''Systemd'' als Abhängigkeit besitzen. Bei Serverinstallationen dürfte dies in der Regel nicht der Fall sein.<br />
<br />
== Siehe auch ==<br />
* [[Debian-Upgrade auf Jessie ohne Systemd]]<br />
<br />
== Weblinks ==<br />
* [http://www.freedesktop.org/wiki/Software/systemd/ Systemd Projektseite] (en)<br />
* [http://unix.stackexchange.com/questions/5877/what-are-the-pros-cons-of-upstart-and-systemd Darlegung von Für/Wider] bei Stackexchange (en)<br />
* [http://0pointer.de/blog/projects/the-biggest-myths.html Mythen über Systemd] (en)<br />
* [http://crunchbang.org/forums/viewtopic.php?id=37871 Systemd loswerden], Beschreibung bei Crunchbang.org (en)<br />
* [http://www.simonrichter.eu/blog/2016-03-03-why-sysvinit.html SimonRichter/ blog/ Why sysvinit?] (en)<br />
* [https://unix.stackexchange.com/questions/218933/after-switching-to-devuan-how-do-i-remove-systemd After switching to Devuan, how do I remove systemd?] (en)<br />
<br />
[[Kategorie:Linux]]</div>PoChttps://kb.pocnet.net/index.php?title=Linux_von_BIOS-_auf_UEFI-Boot_umstellen&diff=2894Linux von BIOS- auf UEFI-Boot umstellen2022-10-15T11:43:39Z<p>PoC: /* Checkliste */ devpts</p>
<hr />
<div>Ohne zu wissen, was es mit EFI auf sich hat, ist das '''Umstellen von Linux von BIOS- auf EFI-Boot''' auf echter Serverhardware (die meistens minutenlang in der internen Firmware rumhängt) zeitraubend und frustrierend. In Kürze Erklärung und Wichtiges:<br />
<br />
== Grundlagen ==<br />
(U)EFI ((Unified) Extensible Firmware Interface) ist mit neuerer Hardware unvermeidbar. Eigentlich ist das Thema sehr einfach: Es gibt keinen binären Bootblock mehr, sondern eine kleine FAT32-Partition zu Beginn der Boot-Disk (ggfs. HW-RAID-Array). Die Bootloader der verschiedenen Betriebssysteme erzeugen eine Verzeichnisstruktur, in welcher dann das eigentliche Startprogramm hinterlegt wird. Die Firmware sammelt beim Systemstart eine Liste der gefundenen ausführbaren Binaries (PE32+ executable) und bietet diese dann zum Start an (bzw. der Standardeintrag wird gestartet).<br />
<br />
== Fallstricke ==<br />
* Ohne Repartitionieren geht es nicht. Da die Umstellung auf EFI durch einem Hardwaretausch mit anschließender Kopie der vorhandenen Installation durchgeführt wird, ist das aber kein Beinbruch.<br />
* Der initiale Boot (CD, ISO-Image, PXE, USB-Stick, usw.) muss zwingend im EFI-Modus mit einem dementsprechend EFI-fähigen Bootmedium durchgeführt werden. Das Debian-Live-Image von Debian 8 oder älter ist nicht geeignet! Erst ab 9 gibt es EFI-Support, z.&thinsp;B. [http://cdimage.debian.org/debian-cd/9.6.0-live/amd64/iso-hybrid/debian-live-9.6.0-amd64-xfce.iso debian-live-9.6.0-amd64-xfce.iso]. Ohne Boot im EFI-Modus sind die EFI-Hooks in der Firmware unsichtbar und Grub-EFI wird mit Fehlern um sich werfen.<br />
* Falls das alte BIOS-Grub-Paket mit <code>--purge</code> gelöscht wird, ist '''unbedingt''' danach ein<br />
grub-install dummy<br />
update-grub<br />
abzusetzen, da das Purge des BIOS-Paketes auch die Konfiguration und weitere Dateien löscht. Nach einem Reboot gibt's ansonsten die Grub-Kommandozeile.<br />
<br />
== Checkliste ==<br />
* Neues System vorbereiten (FW-Updates, BIOS-Settings, usw.),<br />
* Bootmedium vorbereiten (siehe oben),<br />
* Boot via EFI-Bootmenü von diesem Medium,<br />
* Ggfs. manuelle Netzwerkkonfiguration,<br />
* Nachinstallation von benötigten Systemkomponenten (gdisk, mdadm, dosfstools),<br />
* Vorbereiten der Platten für das OS:<br />
** Partitionieren (''gdisk''), dabei (eine) z.&thinsp;B. 100&thinsp;MB große EFI-Partition(en) anlegen, Typ EF00,<ref>Tatsächlich benötigt werden vom Grub-Loader einige 100&thinsp;KBytes.</ref><br />
** Ggfs. Erzeugen der gewünschten Arrays mit ''mdadm'',<br />
** Dateisysteme erzeugen, dabei die EFI-Partition(en) mit einem FAT32-Dateisystem versehen, z.&thinsp;B.: <code>mkfs.fat -F32 /dev/sda1</code>,<br />
** Mounten des OS-Dateisystems nach z.&thinsp;B. ''/mnt'', <code>cd /mnt</code>,<br />
** Kopieren der Installation vom Quellsystem, wie gehabt mit z.&thinsp;B. <code>ssh ''srcsys'' "dump -0a -b 256 -f - /dev/sda1" |restore -r -b 256 -f -</code>,<br />
** Vorbereitungen für ''chroot'': <code>mount -o bind /dev dev/</code>,<br />
* <code>chroot /mnt</code>,<br />
* Nachmounten von Kernel-Pseudo-Dateisystemen: <code>mount -t proc none /proc; mount -t sysfs none /sys; mount -t devpts none /dev/pts</code>,<br />
* Anpassen der ''/etc/fstab'', dabei Eintragen der EFI-Partition(en),<br />
* Mounten der EFI-Partition(en),<br />
* Nachinstallation von benötigten Systemkomponenten (gdisk, mdadm, dosfstools),<br />
* Ggfs. schreiben der RAID-Konfiguration mit <code>/usr/share/mdadm/mkconf > /etc/mdadm/mdadm.conf; update-initramfs -u</code>,<br />
* Austauschen von Grub: <code>apt-get install grub-efi-amd64 grub-efi-amd64-bin</code>,<br />
* Löschen von altem Grub-PC-Kram: <code>dpkg -P grub-pc grub-pc-bin</code>,<br />
* Prüfen, ob ''/etc/default/grub'' existiert und falls nicht, nochmal vom Backup kopieren.<br />
<br />
Grub-EFI erfordert keine Platte mehr als Parameter beim beim Grub-Install. Statt dessen wird als (leider benötigter Parameter) ''dummy'' übergeben.<br />
grub-install dummy<br />
<br />
* Raus aus der chroot: <code>exit</code>,<br />
* Unmounten: <code>umount boot/efi* dev proc sys; cd ..; umount mnt</code>.<br />
<br />
Nach einem Reboot muss die Installation dann wieder sauber hochkommen. Weitere Schritte wie Netzwerkkonfigurationsanpassungen an die neue Hardware sind nicht beschrieben.<br />
<br />
=== Redundanz ===<br />
Beim Booten kann dann statt einem möglicherweise wechselnden Gerät, eine Boot-Konfiguration aus dem genannten Verzeichnis eines beliebigen Gerätes gestartet werden. Vorbei sind die Tage, in denen in einem Software-RAID die erste Platte ausfällt, die zweite Platte dann an die erste Stelle rückt, der Bootblock ist aber nicht auf die erste Platte konfiguriert, sondern entweder überhaupt nicht<ref>Schlampiger Admin…</ref> oder das BIOS kommt mit der neuen BIOS-ID (0x80 statt 0x81) nicht zurecht und verweigert den Boot.<br />
<br />
EFI hat allerdings eine konzeptionelle Schwachstelle: Die Einfachhheit eine ''/boot''-Partition per Software-RAID zu spiegeln ist nicht vorgesehen. Man kann sich was basteln über ''mdadm'' mit nicht persistentem Superblock (damit keine Daten überschrieben werden), aber das ist letztlich alles Gebastel.<br /><br />
Am Einfachsten ist es, manuell die Verzeichnisstruktur auf die zuvor manuell identisch partitionierten und in ''/boot/efi2'', ''/boot/efi3'', usw. gemounteten FAT32-Partitionen zu kopieren.<br />
<br />
Für Debian muss eine Datei angelegt und als ausführbar markiert werden: ''/etc/grub.d/42_update-hook'':<br />
#!/bin/sh<br />
# Dirty hack: If there are multiple FA32-mountpoints in /boot/efi, sync<br />
# contents manually to provide poor man's redundancy.<br />
if mount -t vfat |awk '{print $3}' |grep -q '^/boot/efi$'; then<br />
cat /dev/null > /var/log/update-grub.log<br />
for MP in `mount -t vfat |awk '{print $3}' |grep -v '^/boot/efi$'`; do<br />
rsync -av --delete /boot/efi/ ${MP}/ >> /var/log/update-grub.log<br />
done<br />
else<br />
echo "No EFI Mount Point detected." > /var/log/update-grub.log<br />
fi<br />
<br />
# --EOF--<br />
<br />
Bei jedem Aufruf, der die Grub-Konfiguration neu erzeugt, wird somit auch die Struktur kopiert. Das beinhaltet auch Updates von Kernel und Grub selbst. Fire and forget.<br />
<br />
== Weblinks ==<br />
* [https://outflux.net/blog/archives/2018/04/19/uefi-booting-and-raid1/ UEFI booting and RAID1]<br />
* [https://www.heise.de/newsticker/meldung/Was-Linux-Anwender-ueber-UEFI-wissen-muessen-4204725.html Was Linux-Anwender über UEFI wissen müssen]<br />
* [https://packages.debian.org/stable/bootcd Run your system from cd without need for disks]<ref>Ob das EFI kompatible Images herstellt, ist derzeit nicht bekannt.</ref><br />
* [https://wiki.debian.org/EFIStub …it is possible to load the kernel directly, without any additional bootloader]<br />
<br />
== Fußnoten ==<br />
<references /><br />
<br />
[[Kategorie: Linux]]</div>PoChttps://kb.pocnet.net/index.php?title=Cisco_IOS_XE_Bootschleife&diff=2893Cisco IOS XE Bootschleife2022-10-14T12:42:36Z<p>PoC: Neu</p>
<hr />
<div>Das ''Linux-basierte Cisco IOS XE'' hand habt die <code>boot system</code> Konfiguration anders als die klassischen Router. Es ist daher relativ einfach, die Kisten in einen Zustand zu bekommen, in dem sie ein Image booten, was nicht (mehr) auf dem Bootflash verfügbar ist, anstatt im Fehlerfalle einfach das nächste Image auf dem Flash zu booten.<br />
<br />
C1111-4PLTEEA platform with 4194304 Kbytes of main memory<br />
<br />
<br />
........<br />
<br />
unable to open flash:c1100-universalk9_ias.16.08.03.SPA.bin (14)<br />
<br />
........<br />
<br />
autoboot: boot failed, restarting...<br />
<br />
Resetting .......<br />
<br />
Gerade beim Upgrade auf eine neuere Version, wenn mehrere Reboots für das ROMMON-Upgrade aus dem neueren Image heraus notwendig sind, sind manuelle Boot-Kommandos sehr zeitfressend.<br />
<br />
== Lösung ==<br />
Man muss einen ROMMON-Prompt erhalten. Also direkt nachdem das Gerät auf der Konsole ausgegeben hat was es ist und wie viel RAM es hat, muss ein BREAK gesendet werden. Wie das geht, ist abhängig von der Art und Weise wie auf die Konsole zugegriffen wird (Terminalprogramm).<br />
<br />
An den ROMMON-Prompts kann nun eingegeben werden:<br />
unset BOOT<br />
sync<br />
boot<br />
<br />
[[Kategorie: Cisco]]</div>PoChttps://kb.pocnet.net/index.php?title=Ge%C3%A4ndertes_Copy-Paste-Verhalten_von_Bash_5.1&diff=2892Geändertes Copy-Paste-Verhalten von Bash 5.12022-07-12T08:45:34Z<p>PoC: Neu</p>
<hr />
<div>Nach dem Update von Debian auf Version 11 fällt auf, das '''Copy-Paste''' von Text in die '''Bash''' als "Poor man's Shell Script" sich merkwürdig verhält. Zeilenumbrüche werden nicht mehr mitgenommen und der eingefügte Text wird invers dargestellt.<br />
<br />
Dieses Feature nennt sich ''bracketed paste mode'' und ist seit Bash 5.1 standardmäßig angeknipst.<ref>Siehe NEWS-Datei in den Weblinks, Abschnitt 2h.</ref><br />
<br />
== Wiederherstellung des vorherigen Verhaltens ==<br />
Das Problem ist nicht direkt in der Bash zu suchen, sondern ein Teil der Readline-Library, bzw. deren Einstellungen. Diese werden aus <br />
''/etc/inputrc'' gelesen. Die derzeitigen Einstellungen können mit <code>bind -V</code> ausgelesen werden.<br />
<br />
Das Ergänzen von<br />
set enable-bracketed-paste off<br />
an einer passenden Stelle in der ''/etc/inputrc'' und der Neustart der Shell (Relogin) schalten das neue Verhalten ab.<br />
<br />
== Weblinks ==<br />
* [https://github.com/bminor/bash/blob/8868edaf2250e09c4e9a1c75ffe3274f28f38581/NEWS bminor/bash] NEWS auf GitHub<br />
<br />
== Fußnoten ==<br />
<references /><br />
<br />
[[Kategorie: Bash]]<br />
[[Kategorie: Linux]]</div>PoChttps://kb.pocnet.net/index.php?title=BBEdit_Einstellungen_auf_Standard_nach_Update&diff=2891BBEdit Einstellungen auf Standard nach Update2022-06-30T08:48:20Z<p>PoC: New</p>
<hr />
<div>Seitdem ''TextWrangler'' nicht mehr weiterentwickelt wird und stattdessen eine Light-Version von ''BBEdit'' dessen Funktion übernehmen soll, kommt es immer wieder vor, dass nach einem Upgrade via Appstore die '''Einstellungen von BBEdit wieder zurück auf Standard gesetzt werden'''. Ob dies einem Schluckauf der OS X Sandbox geschuldet ist, oder andere Ursachen hat, lässt sich nicht ohne weiteres feststellen.<br />
<br />
Jedenfalls ist es ärgerlich, wenn die über längere Zeit etablierten Einstellungen plötzlich weg sind.<br />
<br />
== Lokation ==<br />
Die Einstelllungen selbst befinden sich in ''~/Library/Containers/com.barebones.bbedit/Data/Library/Preferences/com.barebones.bbedit.plist''. Diese Datei kann man sich recht einfach aus einem Timemachine-Backup zurückholen.<br />
<br />
Dummerweise sieht die Verzeichnisstruktur im Finder leicht anders aus. Dort ist es ''~/Library/Containers/BBEdit/Data/Library/Preferences/com.barebones.bbedit.plist''. Am Besten man öffnet sich via Terminal-Kommando den standardmäßig versteckten ''Library''-Ordner und hangelt sich via Finder-Fenster durch:<br />
open ~/Library<br />
<br />
Danach markiert man die Prefs-Datei, wählt im Time Machine Menü ''Time Machine öffnen'' und sucht sich einen hinreichend alten Stand raus, definitiv vor dem letzten Upgrade.<br />
<br />
Damit ist das Problem (temporär, bis zu wieder einem anderen Upgrade) gelöst.<br />
<br />
[[Kategorie: Datensicherung]]<br />
[[Kategorie: Mac OS X]]</div>PoChttps://kb.pocnet.net/index.php?title=Apple_SNA%E2%80%A2ps_Konfiguration_f%C3%BCr_5250-Sitzungen&diff=2890Apple SNA•ps Konfiguration für 5250-Sitzungen2022-06-09T13:49:07Z<p>PoC: +Kartenfotos</p>
<hr />
<div>[[Datei:5250term.gif|thumb|right|5250 Clientverbindung via SNA•ps]]<br />
[[Datei:Snagw-run.gif|thumb|right|SNA•ps Gateway Fenster]]<br />
[[Datei:Desktop-Diskimages.gif|thumb|right|Kurz vor der Installation von SNA•ps]]<br />
'''Apple SNA•ps''' ist eine Software, welche die Kommunikation von Apple Macs mit System 7.x mit IBM-Rechnersystemen ermöglicht. Die Kommunikation mit den Rechnern findet hierbei nicht wie heutzutage üblich über IP statt, sondern über Protokolle im Rahmen von '''SNA''' (Systems Network Architecture).<ref>Neuere Versionen vom SNA•ps 5250 Client unterstützen auch IP/tn5250 als Transportweg.</ref><br /><br />
Das Programmpaket wurde als Ergebnis einer erklärten Zusammenarbeit von IBM und Apple Anfang der 1990er Jahre von Orion Software programmiert.<br />
<br />
SNA•ps gibt es zum einen als Gateway mit einer lizenzabhängigen Maximalanzahl von 8, 32 oder 64 [https://en.wikipedia.org/wiki/IBM_Systems_Network_Architecture#Logical_Unit_.28LU.29 LU]-LU Sessions, zum anderen als Client für 5250 Terminal- und Druckservices als auch 3270 Terminalservices. Dieser Artikel konzentriert sich auf das Thema AS/400 bzw. 5250-Anbindung.<br />
<br />
Das SNA•ps Gateway macht Ressourcen, die vom Mainframe oder der AS/400 via [https://en.wikipedia.org/wiki/IBM_Systems_Network_Architecture#Physical_Unit_.28PU.29 SNA PUs] bzw. [https://en.wikipedia.org/wiki/IBM_Advanced_Peer-to-Peer_Networking APPN]/[https://en.wikipedia.org/wiki/IBM_Advanced_Program-to-Program_Communication APPC] bereit gestellt werden, im AppleTalk-Netzwerk verfügbar und umgekehrt. Somit muss nicht in jeden Mac eine (teure) Karte zur Anbindung an das SNA-Netzwerk eingebaut werden, zumal das in manchen Fällen gar nicht möglich ist (kompakte Macs wie der Plus haben keine oder nur eingeschränkte Erweiterungsmöglichkeiten. Zudem ist ggfs. die notwendige Netzwerkverkabelung evtl. nicht vorhanden.)<br /><br />
Beispiele für Clients sind die Terminalemulationen [https://en.wikipedia.org/wiki/IBM_3270 3270], [https://en.wikipedia.org/wiki/IBM_5250 5250]), die dem SNA•ps-Clientpaket beiliegen: Damit können Macs, die nur im [https://en.wikipedia.org/wiki/AppleTalk AppleTalk]-Netzwerk (z.&thinsp;B. via [https://en.wikipedia.org/wiki/LocalTalk LocalTalk]) verbunden sind, Terminalsitzungen zu den SNA-Hosts aufbauen.<br /><br />
Ein Beispiel für die umgekehrte Richtung ist die Druckunterstützung. Der SNA•ps-Print Client emuliert einen IBM 8312-Drucker. Druckjobs, die von einer Druckerqueue auf dem Host dort hin versandt werden, können je nach dem über den in der [https://en.wikipedia.org/wiki/Chooser_(Mac_OS) Auswahl] voreingestellten Drucker gedruckt, oder als Text in eine Datei gesichert werden. Dies war ein Weg, den seinerzeit sehr teuren [https://en.wikipedia.org/wiki/LaserWriter Apple LaserWriter] auch für Großrechner nutzbar zu machen.<br />
<br />
Das Gegenstück zum SNA•ps Gateway ist eine Systemerweiterung ''SNA•ps Access''. Die oben genannten Programme benutzen Routinen, welche diese Erweiterung zu Verfügung stellt. Das SNA•ps API kann somit auch von Drittanbietern genutzt werden. Ein Beispiel hierzu ist [https://en.wikipedia.org/wiki/Database_abstraction_layer DAL] für den Macintosh, welches verschiedene Protokolle für die Verbindung zur eigentlichen Datenbank benutzt; unter Anderem MacTCP (IP) als auch SNA (via SNA•ps Access).<br />
<br />
Für die AS/400 existierten in den 1990er Jahren auch LocalTalk-Zusatzkarten und eine Erweiterung für OS/400, um den AppleTalk-Stack auch auf der AS/400 zu implementieren. Die Implementation auf der AS/400 entsprach dem SNA•ps Gateway, so dass kein Mac als Gateway benötigt wurde: Die notwendige Software lief komplett auf der AS/400.<br />
<br />
== Systemkompatibilität ==<br />
Der SNA•ps 5250 Client benötigt zwingend System 7.0 oder höher. Unter System 6 erhält man eine entsprechende Meldung und der Client startet nicht. Der 3270-Terminalclient startet klaglos unter System 6.0.7.<br />
<br />
Der Client funktioniert unter Systemen bis inkl. 8.1 und OpenTransport auf 68k-Macs. Er läuft nicht mehr auf PowerPC-Macs, der Start einer Verbindung lässt den Client mit einer ''unimplemented instruction'' abstürzen.<br />
<br />
Eine Verbindung via TCP (möglich ab Client Version 1.1) provoziert bereits beim Verbindungsaufbau die Meldung, das Gegenüber könne kein 5250-Protokoll. Nachvollziehbar unter 7.6.1/OT/PPC als auch unter 7.1/MacTCP auf 68k.<br />
<br />
Das Gateway selbst verlangt spezielle Hardware für die SNA-Netzwerkverbindung und ist daher eingeschränkt auf NuBus-Systeme.<br />
<br />
== Transport ==<br />
Folgende Verbindungsmöglichkeiten werden unterstützt:<br />
<br />
{|class="wikitable"<br />
! Phy<br />
! Bemerkungen<br />
|-<br />
|SDLC<br />
|Via Apple Serial NB-Karte<br />
|-<br />
|Token Ring<br />
|Via Apple Token Ring 4/16 NB Karte<br />
|-<br />
|Twinax<ref>5250-Sitzungen über Twinax werden nicht unterstützt. Das hätte mal implementiert werden sollen, dazu kam es allerdings nicht mehr.</ref><br />
|Via Apple Koax/Twinax Karte<br />
|}<br />
<br />
Alle diese Karten haben als Besonderheit eine eigene 68000 CPU und lokalen Speicher und entsprechen der Macintosh Coprocessor Platform Spezifikation. Auf der Karte läuft ein kleiner Prozess, welcher über ''Message Passing'' mit dem Gegenstück ''A/ROSE'' im Mac OS kommuniziert und Daten austauscht.<br />
<br />
Als Besonderheit läuft ein Teil der SNA•ps-Software auf dem Prozessor der jeweiligen Karte. Zusammen mit dem Rest der Software auf Mac OS-Seite werden APPC-Sitzungen in AppleTalk verpackt und können so auch anderen Macs im lokalen Netzwerk zu Verfügung gestellt werden. Auch über Netzwerkverbindungen, welche kein SNA unterstützen wie z.&thinsp;B. LocalTalk.<br />
<br />
<gallery mode="packed"><br />
Datei:Apple-Token-Ring-NB-Compside.jpg|Apple Token Ring 4/16 NB Karte, vorne<br />
Datei:Apple-Token-Ring-NB-Solderside.jpg|Apple Token Ring 4/16 NB Karte, hinten<br />
Datei:Apple-Coax-Twinax-Compside.jpg|Apple Coax/Twinax Karte, vorne<br />
Datei:Apple-Coax-Twinax-Solderside.jpg|Apple Coax/Twinax Karte, hinten<br />
</gallery><br />
<br />
== Konfiguration ==<br />
[[File:Cfg-snaps.gif|thumb|right|183px|Übersicht des Konfigurationsfensters]]<br />
Als Voraussetzung auf AS/400-Seite muss Autokonfiguration für Controller- und Gerätebeschreibungen erlaubt sein: Siehe dazu den Befehl WRKSYSVAL und die Variablen QAUTOCFG, QAUTORMT und QAUTOVRT. Ggfs. ist es sinnvoll, die Variablen QLMTDEVSSN und QLMTSECOFR anzupassen. Zudem wird eine funktionierende Token Ring-Verbindung vorausgesetzt. In der Leitungsbeschreibung muss der Parameter AUTOCRTCTL auf *YES stehen. Es wird empfohlen, den zugehörigen Parameter AUTODLTCTL auf *NONE zu setzen.<br /><br />
Mit dieser Vorbereitung spart man sich die mühsame und fehlerträchtige Konfiguration von OS/400-Controller (*CTLD) und -Gerät (*DEVD) für die Kommunikation mit dem Gateway auf Mac-Seite.<br />
<br />
Die Konfiguration wird mit dem Programm ''SNA•ps Config'' erstellt und schichtweise aufgebaut.<br />
<br />
Es ist problemlos möglich, mehrere AS/400 in einem Konfigurationsdokument zu erfassen. Dazu müssen pro Maschine eigene Definitionen für<br />
* TR Lines,<br />
* Partners,<br />
* Remote 6.2 LUs,<br />
* Modes<br />
erstellt werden. ''Local 6.2 LUs'' und ''TPs'' gelten für das gesamte Dokument.<br />
<br />
Ist eine Maschine im APPN-Verbund als ''Network Node'' konfiguriert, genügt eine Verbindung vom Gateway zu jener Maschine. SNA-APPC Sitzungen werden dann von dort aus weitergeleitet. Es genügt dann, die entsprechenden LUs auf dem Gateway anzulegen.<br />
<br />
=== Line ===<br />
[[File:Cfg-line.gif|thumb|right|183px|Line-Konfiguration]]<br />
Zuerst wird die ''Line''-Konfiguration erstellt. Der Name kann frei gewählt werden. Die Vergrößerung des ''Maximum I-Field Length''-Parameters erhöht den Datendurchsatz und somit die Geschwindigkeit mit welcher Daten durch das Gateway weitergereicht werden. Der höchste akzeptierte Wert ist 4105&thinsp;Bytes. In der ''Line Description'' der AS/400 (was der Line-Konfiguration von SNA•ps entspricht) steht in aller Regel 16393&thinsp;Bytes. Der tatsächlich verwendete Wert wird dynamisch ausgehandelt.<br />
<br />
=== Partner ===<br />
[[File:Cfg-peer.gif|thumb|right|183px|Partnerkonfiguration]]<br />
Solange die erstellte ''Line'' markiert ist, kann im ''Partners''-Feld nebenan die Beschreibung für die eigentliche Netzwerkverbindung zur AS/400 definiert werden. Dabei gelten folgende Parallelen zur AS/400-Konfiguration:<br />
{|class="wikitable"<br />
!Partner-Parameter<br />
!AS/400-Parameter<br />
|-<br />
|Name<br />
|DSPNETA, Name des lokalen Kontrollpunkts (LCLCPNAME)<br />
|-<br />
|Link Address<br />
|WRKLIND, Lokale Adapteradresse (der Token Ring Line) (ADPTADR)<br />
|-<br />
|Partner XID<br />
|WRKLIND, Austausch-ID (der Token Ring Line) (EXCHID)<br />
|-<br />
|Gateway XID<br />
|Selbst würfeln, muss mit 056 beginnen<ref>Dieser Wert wird beim ersten Start per Autokonfiguration auf die AS/400-seitige Controllerbeschreibung übernommen.</ref><br />
|-<br />
|Gateway Network Name<br />
|Selbst würfeln, ggfs. den Namen aus dem Kontrollfeld ''Gemeinschaftsfunktionen'' benutzen<br />
|-<br />
|Gateway Network Qualifier<br />
|DSPNETA, Lokale Netzwerk-ID (LCLNETID)<br />
|}<br />
<br />
Die Charakteristik muss auf ''Peer (Node Type 2.1)'' gesetzt werden. Die ''SAP Address'' bleibt auf 4.<br />
<br />
=== Local 6.2 LUs ===<br />
[[File:Cfg-loclu.gif|thumb|right|183px|Lokale 6.2 LUs]]<br />
{|class="wikitable"<br />
!LU-Parameter<br />
!AS/400-Parameter<br />
|-<br />
|Name: PASSTHRU (wird im Kontrollfeld SNA•ps… der Clients benutzt)<br />
|&nbsp;<br />
|-<br />
|Network LU Name = Gateway Network Name aus der Partner-Konfiguration<br />
|&nbsp;<br />
|-<br />
|Network Qualifier<br />
|DSPNETA, Lokale Netzwerk-ID (LCLNETID)<br />
|}<br />
<br />
=== TPs ===<br />
[[File:Cfg-tp.gif|thumb|right|183px|Transaction Points]]<br />
Die eben definierte ''Local 6.2 LU'' muss markiert sein, damit ein neuer ''Transaction Point'' erstellt werden kann.<br />
* Name: * (Sternchen)<br />
* Network Name = DSPNETA, Lokale Netzwerk-ID der AS/400 (LCLNETID)<br />
<br />
Rest belassen.<br />
<br />
=== Remote 6.2 LUs ===<br />
[[File:Cfg-remlu.gif|thumb|right|183px|Ferne 6.2 LUs]]<br />
Der oben erstellte ''Partner'' muss markiert sein, damit eine zugehörige LU-Konfiguration erstellt werden kann.<br />
* Name = Name des ''Partner''s<br />
* Network LU name = Name des ''Partner''s<br />
* Network Qualifier = DSPNETA, Lokale Netzwerk-ID der AS/400 (LCLNETID)<br />
<br />
Rest belassen.<br />
<br />
=== Modes ===<br />
[[File:Cfg-mode-batchsc.gif|thumb|right|183px|Batch-Modusbeschreibung]]<br />
[[File:Cfg-mode-intersc.gif|thumb|right|183px|Interact-Modusbeschreibung]]<br />
Die oben erstellte ''Remote 6.2 LU'' muss markiert sein, damit eine zugehörige Mode-Konfiguration erstellt werden kann.<br />
<br />
Auf der AS/400 gibt es für deren eigenes Produkt ''Client Access'' eine passende Modusbeschreibung. In der Tabelle sind die passenden Werte eingetragen.<br />
<br />
{|class="wikitable"<br />
!Mode-Parameter<br />
!AS/400-Parameter in WRKMODD<br />
!QPCSUPP-Werte<br />
|-<br />
|Name<br />
|Name der Modusbeschreibung auf AS/400-Seite<br />
|QPCSUPP<br />
|-<br />
|Maximum Sessions<br />
|≤ Maximale Anzahl Sitzungen (MAXSSN)<br />
|64<br />
|-<br />
|Contention Winner<br />
|Lokal gesteuerte Sitzungen, sollte gleich den ''Maximum Sessions'' gehalten werden (LCLCTLSSN)<br />
|64<br />
|-<br />
|Prebound Sessions<br />
|= ''Contention Winner'' (PREESTSSN)<br />
|0<br />
|-<br />
|Send Pacing<br />
|Eingangsdosierwert (INPACING)<br />
|7<br />
|-<br />
|Receive Pacing<br />
|Ausgangsdosierwert (OUTPACING)<br />
|7<br />
|-<br />
|Maximum RU Upper<br />
|Max. Länge Anforderungseinheit (MAXLENRU). Falls dies auf *CALC gesetzt ist, 4096 in ''Maximum RU Upper'' eintragen.<br />
|4096<br />
|}<br />
<br />
Rest belassen.<br />
<br />
Es kann passieren, dass das Gateway nicht startet, weil der Speicher (auf der Karte) nicht ausreicht. Dann empfiehlt es sich, ein<br />
CRTDUPOBJ OBJ(QPCSUPP) FROMLIB(QSYS) OBJTYPE(*MODD) NEWOBJ(APLSNAPS)<br />
abzusetzen und mit ''wrkmodd'' anzupassen: MAXSSN und LCLCTLSSN auf z.&thinsp;B. 32 zu reduzieren. Dies muss logischerweise auch in der SNA ps-Config nachgezogen werden.<br />
<br />
== Aktivierung des Gateways ==<br />
Nachdem die Konfiguration gesichert wurde, wird diese mit dem Programm ''SNA•ps Admin'' der vorhandenen physikalischen Verbindung zugeordnet. Pro SNA-fähiger Verbindungskarte wird im eingeblendeten Fenster ''Network Gateway Status'' eine Zeile angezeigt. Die gewünschte Zeile wird markiert und danach im Menü ''Gateway'' mit ''Select configuration…'' der oben erstellten Konfiguration zugeordnet.<br /><br />
Im selben Menü wird empfohlen, über den Punkt ''Change Settings…''<br />
* dem Gateway einen schöneren Namen zuzuordnen und<br />
* alle Checkboxen bis auf ''Initially Log Line Trace'' unter ''Characteristics'' anzuknipsen.<br />
<br />
Danach kann im Menü ''Gateway'' mit ''Start Gateway'' die Gatewaysoftware gestartet werden.<br />
<br />
Es hat sich gezeigt, dass zumindest mit SNA•ps Version 1.1 das Ausprobieren von Konfigurationsinstellungen mit manuellem Stop und Start manchmal die Meldung provoziert, es wäre zu wenig Speicher vorhanden. Diese Aussage bezieht sich auf den lokalen Speicher auf der entsprechenden Netzwerkkarte. Anscheinend werden Ressourcen dort nicht zuverlässig überschrieben, nach einem Neustart des Rechners ist die Fehlermeldung weg.<br />
<br />
Ebenfalls im Menü ''Gateway'' kann nun mit ''Show Gateway'' eine Übersicht über die vorhandenen Ressourcen angezeigt werden. Ein Beispiel ist im zweiten Screenshot ab Artikelbeginn zu sehen.<br />
<br />
=== Screenshots ===<br />
<gallery mode="nolines"><br />
File:Stat-line.gif<br />
File:Stat-peer.gif<br />
File:Stat-loclu.gif<br />
File:Stat-tp.gif<br />
File:Stat-remlu.gif<br />
File:Stat-mode-snasvcmg.gif<br />
File:Stat-mode-batchsc.gif<br />
File:Stat-mode-intersc.gif<br />
File:Stat-sess-batchsc.gif<br />
File:Stat-sess-intersc.gif<br />
</gallery><br />
<br />
== Client-Konfiguration SNA•ps 5250 ==<br />
Im Kontrollfeld ''SNA•ps Access/5250'' kann in der ''Display Configuration'' auf ''Virtual Controller'' umgestellt werden. Der Controllername ist üblicherweise ''QPACTL01''.<br />
<br />
[[Datei:Dft-connsel.gif|right|thumb|Modaler Dialog zur Auswahl einer Standardsitzung]]<br />
Die Clientkonfiguration beschränkt sich auf die Auswahl der ''Default Connection'' im Menü ''Pref(erence)s''. Alternativ kann im Client die gewünschte Sitzung direkt konfiguriert werden (''Session'', ''Connection…'').<br />
<br />
Danach wird im Menü ''Session'' mit dem Punkt ''Connect'' die Verbindung zum vorab ausgewählten SNA-Gateway hergestellt. Nach einigen Sekunden wird der AS/400 Signon-Screen angezeigt.<br />
<br />
Nebenbei können dann auch noch weitere Parameter gesetzt werden: Größere Schriftart bei entsprechend großen Monitoren, alternative Tastenbelegungen für kleine Mac-Tastaturen (hier bietet sich der Zehnerblock an), usw. Die Einstellungen können in einem Verbindungsdokument gesichert werden. Beim Öffnen eines solchen Dokuments wird die Sitzung automatisch aufgebaut.<br />
<br />
Alle weiteren Einstellungen können je nach Gusto vorgenommen werden.<br />
<br />
== Client-Konfiguration SNA•ps Print ==<br />
Der Print-Client ist nur in der Paketversion 1.0 enthalten. Damit können Druckjobs flexibel gehandhabt werden.<br />
<br />
Im Kontrollfeld ''SNA•ps Access/5250'' muss in der ''Printer Configuration'', ''Printer Device List…'' ein Drucker konfiguriert werden. Dieser sollte auf der AS/400 nicht existieren, damit er mit den richtigen Parametern angelegt wird.<br />
<br />
Nach dem Start von ''SNA•ps Print'' wird nach einem Dateinamen für die nun neu angelegte Druckerverbindung gefragt. Dieses Dokument entsprechend sichern.<br />
<br />
Danach wird im Menü ''Session'' mit dem Punkt ''Connect'' die Verbindung zum vorab ausgewählten SNA-Gateway hergestellt. Die AS/400 legt eine Druckergerätedatei (*DEVD) und eine entsprechende Ausgabewarteschlange (*OUTQ) an. Alles was dort reingestellt wird, landet in der Druckroutine von SNA•ps Print.<br />
<br />
Es wird ein IBM 3812 Model 1 Drucker (SCS) emuliert.<br />
<br />
== Fehlerquellen ==<br />
* Die Benutzung von ''Trawl'' auf dem Gatewayrechner selbst bringt u.&thinsp;U. AppleTalk ins Schleudern, sodass das Gateway nicht mehr im Managertool auftaucht. Dann hilft nur ein Reboot des Gateway-Rechners.<br />
<br />
== Weblinks ==<br />
* Wikipedia (en):<br />
** [https://en.wikipedia.org/wiki/IBM_Systems_Network_Architecture IBM Systems Network Architecture]<br />
** [https://en.wikipedia.org/wiki/IBM_Advanced_Program-to-Program_Communication IBM Advanced Program-to-Program Communication]<br />
** [https://en.wikipedia.org/wiki/IBM_Advanced_Peer-to-Peer_Networking IBM Advanced Peer-to-Peer Networking]<br />
** [https://en.wikipedia.org/wiki/Synchronous_Data_Link_Control Synchronous Data Link Control]<br />
** [https://en.wikipedia.org/wiki/A/ROSE Apple Real-time Operating System Environment]<br />
** [https://en.wikipedia.org/wiki/Message_passing Message Passing]<br />
** [https://en.wikipedia.org/wiki/AppleTalk AppleTalk]<br />
** [https://en.wikipedia.org/wiki/LocalTalk LocalTalk]<br />
* [http://www.mactech.com/articles/develop/issue_04/coprocessor.html Inside The Macintosh Coprocessor Platform And A/ROSE]<br />
* [https://www.computerwoche.de/a/terminalemulation-bindet-apple-welt-an-as-400-mac-user-haben-direkten-zugriff-auf-as-400-daten,1128406 Terminalemulation bindet Apple-Welt an AS/400], Computerwoche 1993-06-11<br />
* [https://www.ibm.com/support/knowledgecenter/en/SSEQ5Y_5.9.0/com.ibm.pcomm.doc/books/html/admin_guide19.htm Administrator's Guide and Reference, SNA Client/Server Concepts], IBM<br />
* [https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.znetwork/znetwork_6.htm Introduction to networking on the mainframe], IBM<br />
* [https://web.archive.org/web/20181229140138/http://docwiki.cisco.com/wiki/IBM_Systems_Network_Architecture_Protocols IBM Systems Network Architecture Protocols], Cisco Docwiki (aus dem Archiv)<br />
<br />
== Fußnoten ==<br />
<references /><br />
<br />
[[Kategorie: AS/400]]<br />
[[Kategorie: Mac OS]]<br />
[[Kategorie: Netzwerk]]</div>PoChttps://kb.pocnet.net/index.php?title=VMware-vSphere-CLI_auf_Debian_installieren&diff=2885VMware-vSphere-CLI auf Debian installieren2022-06-05T11:10:29Z<p>PoC: -kAt</p>
<hr />
<div>Das Installationsscript des '''VMware-vSphere-CLI''' kennt Debian nicht als native Plattform. Folgende Änderungen sind im Installationsscript ''bin/vmware-uninstall-vSphere-CLI.pl'' in Zeile 2283 durchzuführen:<br />
<br />
* Vorher:<br />
if ( direct_command("cat /etc/*-release | grep -i ubuntu") || direct_command("cat /proc/version | grep -i ubuntu") ) {<br />
* Nachher:<br />
if ( direct_command("cat /etc/*-release | grep -i -e debian -e ubuntu") || direct_command("cat /proc/version | grep -i -e debian -e ubuntu") ) {<br />
<br />
Ebenfalls notwendig ist die Installation der angemeckerten fehlenden Dev-Pakete.<br />
<br />
[[Kategorie:Linux]]<br />
[[Kategorie:VMware]]</div>PoChttps://kb.pocnet.net/index.php?title=VMware-vSphere-CLI_auf_Debian_installieren&diff=2884VMware-vSphere-CLI auf Debian installieren2022-06-05T11:10:07Z<p>PoC: Neu</p>
<hr />
<div>Das Installationsscript des '''VMware-vSphere-CLI''' kennt Debian nicht als native Plattform. Folgende Änderungen sind im Installationsscript ''bin/vmware-uninstall-vSphere-CLI.pl'' in Zeile 2283 durchzuführen:<br />
<br />
* Vorher:<br />
if ( direct_command("cat /etc/*-release | grep -i ubuntu") || direct_command("cat /proc/version | grep -i ubuntu") ) {<br />
* Nachher:<br />
if ( direct_command("cat /etc/*-release | grep -i -e debian -e ubuntu") || direct_command("cat /proc/version | grep -i -e debian -e ubuntu") ) {<br />
<br />
Ebenfalls notwendig ist die Installation der angemeckerten fehlenden Dev-Pakete.<br />
<br />
[[Kategorie:Crypto]]<br />
[[Kategorie:Linux]]<br />
[[Kategorie:VMware]]</div>PoChttps://kb.pocnet.net/index.php?title=VMware-vSphere-CLI_Server_version_unavailable_nach_Debian-Upgrade&diff=2883VMware-vSphere-CLI Server version unavailable nach Debian-Upgrade2022-06-05T11:05:20Z<p>PoC: /* Weblinks */ +Kat</p>
<hr />
<div>Nach dem '''Upgrade auf Debian 11''' und der Neuinstallation des '''VMware-vSphere-CLI'''-Paketes funktioniert die Verbindung zum ESXi nicht mehr:<br />
Server version unavailable at 'https://''ESX-URL'':443/sdk/vimService.wsdl' at /usr/share/perl/5.32/VMware/VICommon.pm line 704.<br />
Im Netz verfügbare Tips sind uralt und funktionieren nicht (mehr).<br />
<br />
Ursache ist letztendlich dass nach dem Update die Gültigkeit des vom ESXi präsentierten Zertifikates zwingend überprüft wird.<br />
<br />
== Lösung ==<br />
* Mit OpenSSL das selbstsignierte Zertifikat des ESXi-Servers extrahieren:<br />
openssl s_client -connect ''ESX-URL'':443<br />
* Den präsentierten Textblob zwischen und inklusive der Zeilen ''BEGIN CERTIFICATE'' und ''END CERTIFICATE'' in eine eigene Textdatei sichern.<br />
* Die erzeugte Datei nach ''/usr/local/share/ca-certificates/''ESX-URL''.crt'' verschieben.<br />
* Den systemweiten Zertifikatsindex aktualisieren:<br />
update-ca-certificates<br />
<br />
== Weblinks ==<br />
* [https://github.com/BaldMansMojo/check_vmware_esx/issues/105 Server version unavailable at ISSUE #105], GitHub<br />
* [https://communities.vmware.com/t5/vSphere-SDK-for-Perl-Discussions/Error-Server-version-unavailable-at-https-1-1-1-1-sdk-vimService/td-p/776083 Error: Server version unavailable], VMware Communities<br />
<br />
[[Kategorie:Crypto]]<br />
[[Kategorie:Linux]]<br />
[[Kategorie:VMware]]</div>PoChttps://kb.pocnet.net/index.php?title=VMware-vSphere-CLI_Server_version_unavailable_nach_Debian-Upgrade&diff=2882VMware-vSphere-CLI Server version unavailable nach Debian-Upgrade2022-06-05T11:04:18Z<p>PoC: Neu</p>
<hr />
<div>Nach dem '''Upgrade auf Debian 11''' und der Neuinstallation des '''VMware-vSphere-CLI'''-Paketes funktioniert die Verbindung zum ESXi nicht mehr:<br />
Server version unavailable at 'https://''ESX-URL'':443/sdk/vimService.wsdl' at /usr/share/perl/5.32/VMware/VICommon.pm line 704.<br />
Im Netz verfügbare Tips sind uralt und funktionieren nicht (mehr).<br />
<br />
Ursache ist letztendlich dass nach dem Update die Gültigkeit des vom ESXi präsentierten Zertifikates zwingend überprüft wird.<br />
<br />
== Lösung ==<br />
* Mit OpenSSL das selbstsignierte Zertifikat des ESXi-Servers extrahieren:<br />
openssl s_client -connect ''ESX-URL'':443<br />
* Den präsentierten Textblob zwischen und inklusive der Zeilen ''BEGIN CERTIFICATE'' und ''END CERTIFICATE'' in eine eigene Textdatei sichern.<br />
* Die erzeugte Datei nach ''/usr/local/share/ca-certificates/''ESX-URL''.crt'' verschieben.<br />
* Den systemweiten Zertifikatsindex aktualisieren:<br />
update-ca-certificates<br />
<br />
== Weblinks ==<br />
* [https://github.com/BaldMansMojo/check_vmware_esx/issues/105 Server version unavailable at ISSUE #105], GitHub<br />
* [https://communities.vmware.com/t5/vSphere-SDK-for-Perl-Discussions/Error-Server-version-unavailable-at-https-1-1-1-1-sdk-vimService/td-p/776083 Error: Server version unavailable], VMware Communities<br />
<br />
[[Kategorie: Crypto]]<br />
[[Kategorie: Linux]]</div>PoChttps://kb.pocnet.net/index.php?title=VTAM_Cheat_Sheet&diff=2880VTAM Cheat Sheet2022-02-19T11:48:04Z<p>PoC: Die Seite wurde neu angelegt: „'''VTAM''' is a complex piece of Software. But basically it's just a bit like the UNIX ''inetd'' plus network stack, allowing remote entities to access locally…“</p>
<hr />
<div>'''VTAM''' is a complex piece of Software. But basically it's just a bit like the UNIX ''inetd'' plus network stack, allowing remote entities to access locally defined services.<ref>Yes, this is a daring generalization. But we need to start ''somewhere'' with explanations.</ref><br />
<br />
This article tries to help remembering things. It should serve as a quick reference for handling tasks.<br />
<br />
== Configuration ==<br />
Usually, configuration is stored in a partitioned data set with the partial name ''vtamlst''. To derive it's name, look into ''sys1.proclib(vtam)'' to see the ''dd'' statements. Usually, it's<br />
* ''sys1.vtamlst'', or<br />
* ''sys1.local.vtamlst''.<br />
<br />
Notable members include:<br />
;atcstr*<br />
:Basic configuration. The ''CONFIG'' directive designates which ''atccon''-file to load as default.<br />
;atccon*<br />
:A comma separated list of ''major nodes'' to be handled at VTAM startup.<ref>''Major nodes'' can be activated manually, though.</ref><br />
<br />
Remaining members designate ''major nodes''. That is, textual definition files. This task is usually be done from a TSO session.<br />
<br />
=== Concepts of Major and Minor Nodes ===<br />
VTAM major nodes are roughly member names in the ''vtamlst'' PDS. The first non-comment line starts with a name, the literal ''VBUILD'', <code>TYPE=''node type''</code>, and optional parameters.<br />
<br />
Major node types:<br />
* ADJCP (Adjacent Control Point)<br />
* APPL (Application Program)<br />
* CA (Channel Attachment)<br />
* CDRSRC (Cross-Domain Resources)<br />
* CDRM (Cross-Domain Resource Manager)<br />
* XCA (External Communications Adapter)<br />
* LOCAL (Local SNA)<br />
* LUGROUP (Logical Unit Group)<br />
* MODEL (Model definition for dynamically created PU and LU; mostly for APPN)<br />
* SWNET (Switched, this is the definition of a "real" node)<br />
* DR (Dynamic Reconfiguration or Change)<br />
* ADSSJCP (Adjacent Control Point Table)<br />
* ADJCLUST (Adjacent cluster routing definitions)<br />
* APPNTOSA (APPN-to-subarea Class of Service mapping table)<br />
* SATOAPPN (Subarea-to-APPN Class of Service mapping table)<br />
* BNCOSMAP (Border node CoS mapping definitions)<br />
* NETSRVR (Network node server list)<br />
* GRPREFS (Generic resources preferences table)<br />
* SAMAP (Subarea mapping table)<br />
* SNSFILTR (Session awareness sense filter)<br />
<br />
== Administering VTAM ==<br />
This is done from a system console.<br />
<br />
VTAM is required by TCPIP, but TCPIP is smart enough to cope with VTAM being shut down and restarted without caring for TCPIP.<br />
<br />
=== VTAM Start commands ===<br />
VTAM is usually automatically started in the course of an IPL.<br />
<br />
{|class="wikitable"<br />
!Command<br />
!Comment<br />
|-<br />
|S NET<br />
|VTAM start with defaults<br />
|-<br />
|S NET,,,(LIST=00)<br />
|VTAM start with atcstr''00'' <br />
|}<br />
<br />
=== VTAM Display commands ===<br />
{|class="wikitable"<br />
!Command<br />
!Comment<br />
|-<br />
|D NET,APING,ID=''REMNODE'',LOGMODE=#INTER<br />
|Create an APPC "loopback" session<br />
|-<br />
|D NET,APPLS<br />
|Display VTAM applications status<br />
|-<br />
|D NET,BFRUSE<br />
|Display VTAM buffers in use<br />
|-<br />
|D NET,CDRMS<br />
|Display VTAM cross domains status<br />
|-<br />
|D NET,CDRSCS<br />
|Display VTAM cross domain resources<br />
|-<br />
|D NET,COS<br />
|Display VTAM cos table in use<br />
|-<br />
|D NET,GROUPS<br />
|Display VTAM groups status<br />
|-<br />
|D NET,MAJNODES<br />
|Display a list of '''active''' major nodes<br />
|-<br />
|D NET,NETSRVR<br />
|Display Network Node Server List<br />
|-<br />
|D NET,ID=name<br />
|Display VTAM resource status<br />
|-<br />
|D NET,ID=*.name<br />
|Display VTAM resource status in any net<br />
|-<br />
|D NET,ID=ISTADJCP,E<br />
|Display dynamic list of adjacent CPs<br />
|-<br />
|D NET,RTPS<br />
|Display Rapid Transfer Protocol sessions. RTP is part of HPR.<br />
|-<br />
|D NET,TGPS<br />
|Display Transmission Groups<br />
|-<br />
|D NET,TOPO<br />
|Display APPN Topology<br />
|-<br />
|D NET,TRL<br />
|Display Transport Resource List<br />
|-<br />
|D NET,U,ID=userID<br />
|Display VTAM user ID status<br />
|-<br />
|D NET,VTAMOPTS<br />
|Display VTAM startup options currently set<br />
|}<br />
<br />
=== VTAM Vary commands ===<br />
{|class="wikitable"<br />
!Command<br />
!Comment<br />
|-<br />
|V NET,ACT,ID=name<br />
|Activate VTAM resource<br />
|-<br />
|V NET,INACT,ID=name<br />
|Inactivate VTAM resource<br />
|-<br />
|V NET,DRDS,ID=name<br />
|Activate VTAM dynamic reconfiguration<br />
|}<br />
<br />
=== VTAM Change commands ===<br />
{|class="wikitable"<br />
!Command<br />
!Comment<br />
|-<br />
|F NET,''VTAMOPTS'',''startoption=option''<br />
|Run-Time change VTAM configuration<br />
|-<br />
|F NET,VTAMOPTS,SORDER=APPNFRST<br>F NET,TRACE,ID=''resname'',TYPE=BUF<br>F NET,NOTRACE,ID=''resname'',TYPE=BUF<br />
|valgni="top"|Examples<br />
|}<br />
<br />
=== VTAM Halt commands ===<br />
VTAM won't halt QUICK when application programs are active. Stop with the given commands.<br />
* NFS-Client<ref>If anyone knows how to prevent the NFS-Client from starting at startup, please drop [mailto:poc@pocnet.net me] a note.</ref><br />
P NFSC<br />
* TSO<br />
P TSO<br />
<br />
{|class="wikitable"<br />
!Command<br />
!Comment<br />
|-<br />
|Z NET,CANCEL<br />
|VTAM abnormal termination command<br />
|-<br />
|Z NET,QUICK<br />
|VTAM somewhat faster termination command<br />
|-<br />
|Z NET<br />
|VTAM normal termination command<br />
|}<br />
<br />
== Literature ==<br />
* IBM z/OS Basic Skills Information Center: [https://www.ibm.com/docs/en/zos-basic-skills?topic=networking-zos ''Networking on z/OS''] <br />
* IBM Redbook: ''P/390, R/390, S/390 Integrated Server: OS/390 New User′s Cookbook'', document number [https://ibmdocs.pocnet.net/SG24-4757-01.pdf SG24-4757-01]<br />
<br />
== Footnotes ==<br />
<references /><br />
<br />
[[Category: MVS]]</div>PoChttps://kb.pocnet.net/index.php?title=TSO_Autologout&diff=2879TSO Autologout2022-02-19T11:47:18Z<p>PoC: Die Seite wurde neu angelegt: „If your 3270 session isn't used for a certain amount of time, it will time out and your session will be terminated. There are some possibilities to work around…“</p>
<hr />
<div>If your 3270 session isn't used for a certain amount of time, it will time out and your session will be terminated. There are some possibilities to work around that.<br />
<br />
;Put your session into an auto-update state, so it will not timeout.<br />
:This one can be found in websites on the internet quite often as a solution. You need to set the mode manually before the terminal will sit idle, though. Because of that I think this isn't a proper solution.<br />
;Raise a global job timeout parameter.<br />
:You need to edit ''SYS1.PARMLIB(SMFPRM00)'' and raise the JWT (Job Wait Timeout) parameter contained within to your liking. The exact format of the JWT variable isn't clear to me. Some sources state it's in ''HHMM'' format, others state, it's the number of minutes until timeout. Maybe it also depends on the OS version used. Unfortunately, this parameter doesn't affect just TSO sessions but all jobs in the system. Additionally, it's not clear how exactly to activate changes without the need to IPL. Your mileage may vary.<br />
;Modify the TSO logon procedure to set a higher default for TSO sessions only.<br />
:You can find the logon procedure JCL in ''SYS1.PROCLIB(TSOLOGON)''. In the line with the ''IKJACCNT''-statement, simply add a <code>,TIME=1440</code> to the end of the line and save. Since it's a procedure which is called at every logon, no further action should be needed.<br />
<br />
== Weblinks ==<br />
* [http://ibmmainframes.com/about13984.html how to prolong the time to stay in TSO]<br />
<br />
[[Category: MVS]]</div>PoChttps://kb.pocnet.net/index.php?title=IFB030I_SYS1.LOGREC_I/O_ACCESS_ERROR&diff=2878IFB030I SYS1.LOGREC I/O ACCESS ERROR2022-02-19T11:46:24Z<p>PoC: Die Seite wurde neu angelegt: „Error message on console while IPLing: / IFB030I SYS1.LOGREC I/O ACCESS ERROR,0008,0E00,21.47.41 Solution: Run this JCL. //CLEARLOG JOB //CLEAR EXEC PROC…“</p>
<hr />
<div>Error message on console while IPLing:<br />
/ IFB030I SYS1.LOGREC I/O ACCESS ERROR,0008,0E00,21.47.41 <br />
<br />
Solution: Run this JCL.<br />
//CLEARLOG JOB<br />
//CLEAR EXEC PROC=CLEARERP<br />
<br />
Re-IPL.<br />
<br />
== Weblinks ==<br />
* [https://turnkey-mvs.yahoogroups.narkive.com/aSUmpDlE/errors-during-shutdown-ifb030i-iea000i Errors during shutdown (IFB030I & IEA000I)], Turnkey-MVS Mailing List Archive<br />
<br />
[[Category: MVS]]</div>PoChttps://kb.pocnet.net/index.php?title=COBOL-ASSIGN-CLAUSE&diff=2877COBOL-ASSIGN-CLAUSE2022-02-19T11:45:06Z<p>PoC: Neu</p>
<hr />
<div>When ASSIGNing a COBOL-internal file name to an external file (aka: DDname), the external name is prefixed with certain strings to establish the type (class) of device and record organization. The external name is also called the ''system name'' of a file, while ''somefile'' is the COBOL-internal name.<br />
<br />
SELECT SOMEFILE ASSIGN TO CLASS-ORGANIZATION NAME.<br />
<br />
The device classes are:<br />
:{|class="wikitable"<br />
!Code<br />
!Class<br />
|-<br />
|DA<br />
|Direct Access (mass storage)<br />
|-<br />
|UR<br />
|Unit Record (card reader/punch and printers)<br />
|-<br />
|UT<br />
|UTility (generally tape or PS disk)<br />
|}<br />
<br />
The organisation could have the following values:<br />
:{|class="wikitable"<br />
!Code<br />
!Organization type<br />
!Valid for Classes<br />
|-<br />
|S<br />
|standard sequential<br />
|DA, UR, UT<br />
|-<br />
|D<br />
|direct access<br />
|DA<br />
|-<br />
|R<br />
|relative access<br />
|DA<br />
|-<br />
|I<br />
|ISAM (Indexed Sequential Access Method)<br />
|DA<br />
|}<br />
<br />
== Weblinks ==<br />
* [https://turnkey-mvs.yahoogroups.narkive.com/Hf2qN6Ls/cobol-select-and-assign Cobol Select and Assign], Turnkey-MVS Group archive<br />
<br />
[[Category: MVS]]<br />
[[Category: Programmierung]]</div>PoChttps://kb.pocnet.net/index.php?title=Automatic_Startup_and_Shutdown_of_TK4-_with_Hercules_on_Linux&diff=2876Automatic Startup and Shutdown of TK4- with Hercules on Linux2022-02-19T11:43:20Z<p>PoC: Die Seite wurde neu angelegt: „When Hercules is running as one background task of many on some server machine, it could happen that the host machine is rebooted and Hercules killed abruptly…“</p>
<hr />
<div>When Hercules is running as one background task of many on some server machine, it could happen that the host machine is rebooted and Hercules killed abruptly in the course of action. Thus, some means of '''Automatic Startup and Shutdown of Hercules''' is desired.<br /><br />
There are multiple ways to accomplish this goal. I chose the described procedure because it's still less work than integrating the said handling into the system startup procedures.<br />
<br />
The directions provided make Hercules being run as ordinary user (not ''root''), on on a Debian System. The TK4- install is placed directly into the home directory of the said user.<ref>Must be created separately, for example with <code>adduser</code>.</ref><br />
<br />
== Startup ==<br />
To have access to the console, Hercules is started in interactive mode within a ''screen''-session. Actual start is handled by ''cron'' through the ''@reboot'' directive in the user's ''crontab''.<br />
@reboot screen -d -m -S hercules-mvs -- ./mvs<br />
Before activating, make sure, that the TK4--specific file ''~/unattended/mode'' contains the word ''CONSOLE''. If not, make the appropriate change.<br />
<br />
Keep in mind that if you log in as ''root'' and switch users afterwards, you can't reconnect to the session with <code>screen -r</code>, because of TTY authorization issues. See [[#Weblinks|Weblinks]] below for solutions.<br />
<br />
=== Advanced Startup ===<br />
Normally, any OS running on a real Mainframe needs a System console. Fortunately, at least ''TK4-'' was modified in a way that the system console has been redirected to the Hercules console.<br />
<br />
For other OS, like VM "Sixpack", this is not the case. To ease startup we want to run Hercules in a Screen-Session as outlined above, but we want a second window in that session to automatically start c3270 to connect to localhost and provide a system console without further intervention.<br />
<br />
This can be achieved with a simple ''~ /.screenrc'' for the user running the Hercules instance:<br />
# don't display the copyright page<br />
startup_message off<br />
<br />
# increase scrollback buffer size<br />
defscrollback 10000<br />
<br />
# create windows<br />
screen -t hercules-vm hercules -f hercules.cnf<br />
sleep 1<br />
width -w 25 80<br />
screen -t 3270-con c3270 localhost:3270<br />
detach<br />
<br />
It is important that the screen geometry must be set before the startup of c3270. If it's not set, it will not start. The sleep gives Hercules some time to open the Console Port for c3270 to connect to.<br />
<br />
Afterwards, the cronjob must be modified slightly:<br />
@reboot screen -S hercules-vm<ref>Not yet tested if the ''cron'' startup really works.</ref><br />
<br />
=== Network Preconfiguration ===<br />
Understanding Hercules Networking can be a real challenge if you're not used to coping with TUN/TAP interfaces yet. Unfortunately, current documentation on this Facility is scarce.<br />
<br />
While Hercules can make use of an external program <code>hercifc</code>, posts in the Hercules-390 group suggest there's a memory leak eating up a considerable amount of RAM. For that I opted to use a preconfigured interface.<br />
<br />
So, I added into ''/etc/rc.local'':<br />
echo "Create TUN-Device for Hercules instance..."<br />
/sbin/ip tuntap add mode tun user vmrun && \<br />
/sbin/ifconfig tun0 10.59.0.2 netmask 255.255.255.0<br />
<br />
This configures a local interface for the TUN/TAP API which Hercules uses for Networking. The ''user'' parameter even enables us to get rid of the need to run ''Hercules'' as ''root'' because network access usually requires that. The peer IP has to be set in the OS running within Hercules. I assumed to have it be in the same subnet as created with the above commands. '''This IP subnet must be different from any subnet in your network!'''<br />
<br />
In the Hercules configuration, it's just a line like the following:<br />
0E20-0E21 CTCI tun0<br />
<br />
This enables us to access the hosts IP stack from within Hercules. All further configuration has to be done there.<br />
<br />
But how to access that stuff from other hosts in your network? This involves to enable IP forwarding and some tweaks on your internet gateway.<br />
<br />
To enable IP forwarding, edit ''/etc/sysctl.conf'' and add:<br />
net.ipv4.ip_forward = 1<br />
<br />
Afterwards, run <code>sysctl -p</code> to activate the change.<br />
<br />
Last step involves setting a ''static route'' in whatever your internet gateway is.<ref>Imagine you want to connect from a LAN host of yours with the IP address 192.168.178.63 to the OS within Hercules. So, the LAN host sends a packet. 10.59.0.0/24 is different from 192.168.178.0/24, so the packet is addressed to your internet gateway. This sends out the packet into the internet, because it doesn't know where else to send it. The packet is lost and there's no connection.</ref> In this example, you need to add a route with the destination address 10.59.0.0, the netmask 255.255.255.0. The gateway address is the address of your Hercules hosting Machine's Ethernet Interface.<br />
<br />
== Shutdown ==<br />
The shutdown procedure is a bit more interesting, because it's necessary to initiate a system shutdown of MVS from outside MVS, in a non-interactive way. Fortunately, there's the virtual card reader device listening on Port 3505 for input and passing data to JES2.<br />
<br />
So, my solution submits a shutdown-JCL to the card reader (and times out after one second, because the card reader ignores EOF), and waits in a loop until there's no more Hercules process to be seen.<ref>Drawback is that this works for only one Hercules instance per Host.</ref> It needs ''netcat'' to be installed, to submit data to the TCP port.<br />
<br />
#!/bin/bash<br />
# <br />
# rc.local.shutdown<br />
#<br />
# Make sure that the script will "exit 0" on success or any other<br />
# value on error.<br />
#<br />
# In order to enable or disable this script just change the execution<br />
# bits.<br />
#<br />
# By default this script does nothing.<br />
<br />
echo "Signalling TK4-/Hercules to shut down, please wait at most 4 Minutes..."<br />
/bin/nc -w1 localhost 3505 <<EOF<br />
//EXTSHUT JOB (TK4-), 'Shutdown TK4-',<br />
// CLASS=A, MSGCLASS=A, MSGLEVEL=(0,0),<br />
// USER=HERC01,PASSWORD=CUL8TR<br />
//SHUTDOWN EXEC SHUTDOWN<br />
EOF<br />
<br />
N=0<br />
<br />
while ps ax |fgrep -v grep |fgrep -q 'hercules -f conf/tk4-.cnf'; do<br />
sleep 12<br />
((N++))<br />
<br />
# Time out after 4 Minutes, let sysvrc kill hercules.<br />
if [ ${N} -ge 20 ]; then<br />
echo "Hercules shutdown timeout after 4 Minutes, giving up."<br />
break<br />
fi<br />
done<br />
<br />
if [ ${N} -lt 20 ]; then<br />
echo "Hercules shutdown finished."<br />
fi<br />
<br />
exit 0<br />
<br />
=== Enabling the handling of ''rc.local.shutdown'' on Debian ===<br />
Stock Debian installs have no shutdown-equivalent of ''/etc/rc.local''. Therefore, changes need to be made to ''/etc/init.d/rc.local'' as outlined in the following ''diff'':<ref>I am using Debian 10 with Standard SysV-Init. Most likely, you'll need to make changes for ''Systemd'' based systems elsewhere.</ref><br />
--- /etc/init.d/rc.local 2015-04-06 17:50:43.000000000 +0200<br />
+++ rc.local.new 2020-06-03 15:44:02.848720538 +0200<br />
@@ -24,6 +24,16 @@<br />
fi<br />
}<br />
<br />
+do_stop() {<br />
+ if [ -x /etc/rc.local.shutdown ]; then<br />
+ [ "$VERBOSE" != no ] && log_begin_msg "Running local shutdown scripts (/etc/rc.local.shutdown)"<br />
+ /etc/rc.local.shutdown<br />
+ ES=$?<br />
+ [ "$VERBOSE" != no ] && log_end_msg $ES<br />
+ return $ES<br />
+ fi<br />
+}<br />
+<br />
case "$1" in<br />
start)<br />
do_start<br />
@@ -32,10 +42,14 @@<br />
echo "Error: argument '$1' not supported" >&2<br />
exit 3<br />
;;<br />
- stop|status)<br />
+ status)<br />
# No-op<br />
exit 0<br />
;;<br />
+ stop)<br />
+ do_stop<br />
+ exit 0<br />
+ ;;<br />
*)<br />
echo "Usage: $0 start|stop" >&2<br />
exit 3<br />
<br />
== Weblinks ==<br />
* [https://stackoverflow.com/questions/21328140/screen-cannot-open-your-terminal-dev-pts-0-please-check Screen Cannot open your terminal '/dev/pts/0' - please check], Stackoverflow<br />
<br />
== Footnotes ==<br />
<references /><br />
<br />
[[Category: MVS]]</div>PoChttps://kb.pocnet.net/index.php?title=7_Days_To_Die_Dedicated_Server_auf_Debian_Linux_via_Kommandozeile_installieren&diff=28737 Days To Die Dedicated Server auf Debian Linux via Kommandozeile installieren2022-02-01T17:50:21Z<p>PoC: /* Installation */ Fehlermöglichkeiten</p>
<hr />
<div>Die Installation eines '''7 Days To Die Dedicated Servers auf auf Debian Linux via Kommandozeile''' ist nicht ganz trivial. Das gilt vor allem für die Inbetriebnahme des Steam-Clients für die Kommandozeile.<br />
<br />
Der Server benötigt rund 6,4&thinsp;GiB Platz auf der Platte und rund 2&thinsp;GiB RAM (ohne Spieler).<br />
<br />
== Steam-Client ==<br />
Als Grundvoraussetzung für alle Steam-Themen muss zuerst mal der Client installiert und grundkonfiguriert werden. Das passiert am Besten als ''root'', um den Client systemweit für alle Benutzer anbieten zu können.<br />
<br />
=== Download und Auspacken ===<br />
Im Zielverzeichnis müssen rund 250&thinsp;MiB Platz vorhanden sein.<br />
cd /tmp<br />
wget <nowiki>http://media.steampowered.com/installer/steamcmd_linux.tar.gz</nowiki><br />
mkdir /opt/steamcmd<br />
cd /opt/steamcmd<br />
tar xzf /tmp/steamcmd_linux.tar.gz && rm -f /tmp/steamcmd_linux.tar.gz<br />
<br />
=== Initialer Start ===<br />
./steamcmd<br />
<br />
Hier scrollt nun eine Menge Text durch mit Hinweisen über Downloads und Pakete. Am Ende muss ein fett gedruckter Prompt da stehen:<br />
'''Steam>'''<br />
<br />
Der Client kann an dieser Stelle mit <code>quit</code> verlassen werden.<br />
<br />
=== Berechtigungen einrichten ===<br />
groupadd steam<br />
chgrp -R steam /opt/steamcmd<br />
find /opt/steamcmd -type d -exec chmod 2775 {} \;<br />
find /opt/steamcmd -type f -exec chmod 664 {} \;<br />
find /opt/steamcmd -type f -a \( -name "*.sh" -o -name "*.so" -o -name "*.so.*" \) -exec chmod -v 755 {} \;<br />
chmod a+x /opt/steamcmd/linux32/*<br />
chmod 2770 /opt/steamcmd<br />
<br />
=== Suchpfad ergänzen ===<br />
vi /etc/profile<br />
<br />
Natürlich kann man den Editor seiner Wahl verwenden. Letztendlich kommt es darauf an, in den Zeilen, in denen die <code>PATH</code>-Variable gesetzt wird, den Pfad zum Steam-Client zu ergänzen.<br />
<br />
;Vorher:<br />
if [ "`id -u`" -eq 0 ]; then<br />
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11"<br />
else<br />
PATH="/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games"<br />
fi<br />
<br />
;Nachher:<br />
if [ "`id -u`" -eq 0 ]; then<br />
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/opt/steamcmd"<br />
else<br />
PATH="/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/opt/steamcmd"<br />
fi<br />
<br />
Optional können nun bereits auf dem System angelegte Benutzer in die Gruppe ''steam'' aufgenommen werden.<br />
useradd reiner steam<br />
(Im Beispiel heißt der vorhandene Benutzer ''reiner''.)<br />
<br />
Damit sind die vorbereitenden Arbeiten für den Client abgeschlossen.<br />
<br />
== Server ==<br />
Sinnvollerweise richtet man den Server so ein, dass er unter einem eigenen Benutzer läuft. Dazu fügen wir den Benutzer sdtd hinzu:<br />
adduser --ingroup steam --disabled-password --gecos 'Seven Days To Die Dedicated Server Account' sdtd<br />
<br />
=== Installation ===<br />
Nun installieren wir den Server. Ganz wichtig ist, dass in ''/home'' genügend freier Platz zu Verfügung steht. Ausgepackt bringt der Server derzeit 6,4&thinsp;GiB an Daten mit!<br />
su - sdtd<br />
steamcmd.sh<br />
<br />
Ab hier ist nun nach jeder Eingabe der <code>'''Steam>'''</code>-Prompt sichtbar.<br />
login anonymous<br />
app_update 294420 validate<br />
<br />
Der Download wird nun durchgeführt und dauert seine Zeit.<br />
<br />
Folgende Fehler sind derzeit bekannt:<br />
* <code>Error! App '294420' state is 0x202 after update job.</code>: Nicht genügend freier Platz in ''/home/sdtd/Steam''.<br />
* <code>Error! App '294420' state is 0x426 after update job.</code>: Servertask läuft noch. Muss vorher beendet werden.<br />
<br />
Nach dem Update kann der Client wiederum beendet werden:<br />
quit<br />
<br />
=== Konfiguration ===<br />
Die Konfiguration findet sich in ''~/Steam/steamapps/common/"7 Days to Die Dedicated Server"/serverconfig.xml''.<br />
<br />
Mit <code>telnet localhost 8081</code> kann der Server via Kommandozeile gesteuert werden (sofern er läuft).<br />
<br />
Weiteres wird noch ergänzt.<br />
<br />
=== Automatischer Start ===<br />
Damit der Server nach dem automatischen Start ordnungsgemäß im Hintergrund weiterläuft, muss im Startscript eine Anpassung vorgenommen werden: Die eigentlichen Startzeilen müssen mit einer Leerstelle und Kaufmanns-und (&) abgeschlossen werden:<br />
;Vorher:<br />
./7DaysToDieServer.x86_64 -logfile 7DaysToDieServer_Data/output_log__`date +%Y-%m-%d__%H-%M-%S`.txt -quit -batchmode -nographics -dedicated $PARAMS<br />
<br />
;Nachher:<br />
./7DaysToDieServer.x86_64 -logfile 7DaysToDieServer_Data/output_log__`date +%Y-%m-%d__%H-%M-%S`.txt -quit -batchmode -nographics -dedicated $PARAMS &<br />
<br />
Durch den nachfolgenden Cronjob wird der Server nach einem Reboot automatisch gestartet. Muss mit <code>crontab -e</code> als Benutzer ''sdtd'' eingefügt werden:<br />
@reboot cd ~/Steam/steamapps/common/'7 Days to Die Dedicated Server' && ./startserver.sh -configfile=serverconfig.xml<br />
<br />
Mit der o.&thinsp;G. Zeile als Benutzer ''sdtd'', ohne das ''@reboot'' vornedran kann der Server dann gestartet und die Shell alsdann geschlossen werden (logout).<br />
<br />
==== Server beenden ====<br />
Mit dem Konsolen-Kommando (telnet, s.&thinsp;O.) ''shutdown'' kann der Server ordnungsgemäß beendet werden. Ob das auch bei einem normalen ''kill''-Kommando im Rahmen eines Host-Reboots so ordentlich läuft, ist derzeit unklar.<br />
<br />
== Debugging ==<br />
Im Unterordner ''7DaysToDieServer_Data'' findet sich ein ''output_log'' mit Timestamp hintendran, da landen die Ausgaben vom Server drin.<br />
<br />
== Firewall ==<br />
Der Server öffnet folgende Ports:<br />
* tcp/127.0.0.1:8081 (Management)<br />
* tcp/26900<br />
* udp/26900<br />
* udp/26902<br />
<br />
Die letzten drei müssen in einer ggfs. vorhandenen Firewall bzw. einem NAT-Router entsprechend geöffnet bzw. weitergeleitet werden.<br />
<br />
== Weblinks ==<br />
* [https://wiki.dawico.de/display/WIKI/7+Days+To+Die%3A+dedicated+Server+auf+Debian+installieren 7 Days To Die: dedicated Server auf Debian installieren] (fehlerhaft, aber als initialer Start für diesen Artikel gut geeignet)<br />
* [https://7daystodie.gamepedia.com/Server Server-Dokumentation] im 7 Days to Die Wiki<br />
* [https://unix.stackexchange.com/questions/463708/uninstall-a-steam-game-with-the-console Uninstall a Steam game with the console], Stack Exchange<br />
* [https://steamcommunity.com/sharedfiles/filedetails/?l=german&id=360404397 Installing Linux dedicated server for 7 days to die] mit Tips zur Installation von experimentellen Releases.<br />
<br />
[[Kategorie: Linux]]<br />
[[Kategorie: Spiel]]</div>PoChttps://kb.pocnet.net/index.php?title=AS/400_Journaling&diff=2871AS/400 Journaling2021-12-30T10:31:30Z<p>PoC: Überarbeitet, Remote-Journals eingearbeitet</p>
<hr />
<div>Die AS/400-Plattform beinhaltet die Möglichkeit, Änderungen an Datenbankdateien aufzuzeichnen. Dies wird dort als '''Journaling''' bezeichnet.<br />
<br />
Die Implementation greift auf zwei Objektarten der AS/400 zurück:<br />
* '''Das Journal''' wird mit den zu überwachenden Datenbankdateien verknüpft und extrahiert die gewünschten Änderungen,<br />
* '''der Journalempfänger''' wird mit dem Journal verknüpft und dient als Container für die Aufzeichnungen.<br />
<br />
Journalling ermöglicht z.&thinsp;B.<br />
* die punktgenaue Wiederherstellung einer Datenbankdatei, nachdem diese von einer Sicherung zurückgespeichert werden musste. Ebenso ist es möglich, einen älteren Stand einer Datenbankdatei wieder herzustellen. Beides wird mit dem Befehl WRKJRN und den zugehörigen Optionen erreicht.<br />
* geöffnete Datenbankdateien in konsistentem Zustand zu sichern.<br />
* schreibende Datenbankoperationen zu bündeln und entweder alle anzuwenden, oder keine: Transaktionen.<ref>Dazu sind allerdings noch Anpassungen im Programmcode notwendig.</ref><br />
<br />
== Journaling einrichten ==<br />
Mit der Taste <code>F4</code> kann wie gehabt die Formulardarstellung als Ausfüllhilfe für die einzelnen Parameter aufgerufen werden.<br />
<br />
=== CRTJRNRCV ===<br />
Zuerst muss ein (leerer) Journalempfänger eingerichtet werden. Bei der Einrichtung empfiehlt es sich, eine Empfängerschwelle einzurichten. Das ist die Angabe der maximalen Größe in KiB. Als Name ist es vorteilhaft, den Namen selbst mit nachfolgenden Ziffern bis zur maximalen Länge aufzufüllen. Z.&thinsp;B. ''myrcv00001''.<br />
<br />
=== CRTJRN ===<br />
Danach wird das Journal selbst erzeugt und im gleichen Schritt mit dem eben angelegten Empfänger verknüpft. Wenn die Empfängerverwaltung auf ''*SYSTEM'' umgestellt wird, nimmt einem das OS das regelmäßige Putzen ab: Wenn der oben genannte Schwellwert überschritten wurde, wird automatisch ein neuer Empfänger mit einer um eins höheren fortlaufenden Nummer erzeugt und angehängt. Der Schwellwertparameter wird vom bestehenden Empfänger übernommen.<br /><br />
Ebenso ist es möglich, alte Empfänger automatisch löschen zu lassen. Als Voraussetzung müssen diese gesichert worden sein (SAVLIB o.&thinsp;Ä.). Ob das sinnvoll ist, ist individuell von der eigenen Sicherungsstrategie abhängig.<br /><br />
Um Platz zu sparen kann der Parameter RCVSIZOPT(*RMVINTENT) benutzt werden. Angehängte Journalempfänger werden dann von internen Einträgen befreit, die nur für eine Wiederherstellung im Rahmen eines abnormalen IPLs benötigt werden.<br />
<br />
=== STRJRNPF ===<br />
Nun müssen noch die gewünschten Datenbankdateien mit dem Journal verknüpft werden. Bei dieser Verknüpfung kann angegeben werden, welche Daten erfasst werden. Im Regelfall kann auf Journaleinträge verzichtet werden, die nun Öffnen und Schließen der Datei anzeigen. Umgekehrt kann es sinnvoll sein, das Vorherige ''und'' nachfolgende Abbild eines Datensatzes aufzuzeichnen. Ein Fehler ist so ohne globalen Eingriff (mit der verbundenen jetzt-niemand-an-der-DB-fummeln) durch Journalrollbacks schnell korrigiert (DSPJRN).<br />
<br />
==== Journaling von Zugriffspfaden ====<br />
Zugriffspfade sind in der herkömmlichen Datenbankwelt als Index bekannt.<br /><br />
Die Aufzeichnung von Zugriffspfaden via ''STRNJRNAP'' ermöglicht dem Betriebssystem nach einem Stromausfall o.&thinsp;Ä. die schnellere Wiederherstellung eines konsistenten Zustandes. Dieses Feature scheint daher vor allem bei großen DB-Dateien sinnvoll, während die Zeitersparnis bei wenigen Megabytes großen Datenbanken eher gering sein dürfte.<br />
<br />
== Journaling rückbauen ==<br />
Der Rückbau von Journaling findet in umgekehrter Reihenfolge statt:<br />
* Verknüpfung mit Datenbankdateien lösen (ENDJRNPF, ggfs. vorher ENDJRNAP),<br />
* Journal löschen (DLTJRN),<br />
* Journalempfänger löschen (DLTJRNRCV).<br />
<br />
Die beiden letzten Punkte können auch einfacher durch die Ansicht in ''WRKLIB'', Option 12 erreicht werden.<br />
<br />
== Ferne Journale ==<br />
Ein ''Fernes Journal'' ist nichts weiter als die automatische Replikation von Journals auf eine weitere AS/400.<br /><br />
Diese Journaldateien können einfach nur gelagert werden, um im Falle eines Falles darauf zugreifen zu können; oder diese können benutzt werden, um eine dort befindliche Kopie der Datenbank auf dem jeweils aktuellen Stand zu halten.<br />
<br />
Im Folgenden gilt:<br />
* Die ''Quell''maschine ist die primäre AS/400, auf der die Produktivdatenbank liegt,<br />
* die ''Ziel''maschine ist das Backupsystem.<br />
<br />
=== Vorarbeiten ===<br />
Quell- und Zielmaschine müssen miteinander kommunizieren können. Das Mittel der Wahl für V4R5 ist Remote-Journaling via SNA.<br />
<br />
Die Quellmaschine muss einen Eintrag für die Zielmaschine in ihrem Verzeichnis der bekannten ''relationalen Datenbanken'' erhalten. Dies kann mit ''WRKRDBDIRE'' vorgenommen werden.<br /><br />
Falls noch kein Eintrag für die Quellmaschine (Typ *LOCAL) vorhanden ist, muss dieser ebenfalls hinzugefügt werden.<br />
<br />
Auf der Zielmaschine wird sinnvollerweise ein Benutzer samt Library eingerichtet, mit dem sich die Quellmaschine auf die Zielmaschine verbinden darf (CRTLIB, CRTUSRPRF, CHGOBJOWN).<br />
<br />
Der eingerichtete Benutzer muss nun auf der hinterlegt werden (ADDSVRAUTE). Dabei ist als lokales Benutzerprofil dasjenige zu hinterlegen, mit dem später die eigentliche Journalverbindung eingerichtet wird.<br />
<br />
* Auf der Quellmaschine:<br />
ADDRMTJRN RDB(DSTMACH) SRCJRN(MYJRN) TGTJRN(MYJRN) RMTRCVLIB(MYLIB) RMTJRNTYPE(*TYPE2)<br />
CHGRMTJRN RDB(DSTMACH) SRCJRN(MYJRN) TGTJRN(MYJRN) JRNSTATE(*ACTIVE)<br />
<br />
Bereits vorhandene Einträge werden nun übertragen.<br />
<br />
* Rückbau:<br />
RMVRMTJRN RDB(RMTMACH) SRCJRN(MYJRN) TGTJRN(MYJRN)<br />
<br />
== Weblinks ==<br />
* [http://public.dhe.ibm.com/systems/power/docs/systemi/v5r3/en_US/rzaki.pdf iSeries Journal Management], IBM<br />
* [https://docs.starquest.com/Products/sqdrplus/SQDRManager.hlp/Configuring_Remote_Journaling_on_the_DB2_for_i_Source.htm Configuring Remote Journaling on the DB2 for i Source]<br />
* [http://search400.techtarget.com/tip/Tips-for-using-Remote-Journal Tips for using Remote Journal]<br />
<br />
== Fußnoten ==<br />
<references /><br />
<br />
[[Kategorie:AS/400]]<br />
[[Kategorie:Datenbank]]</div>PoChttps://kb.pocnet.net/index.php?title=Apple_TimeMachine_Backup_in_Disk_Image&diff=2868Apple TimeMachine Backup in Disk Image2021-09-12T17:21:45Z<p>PoC: Anpassungen</p>
<hr />
<div>'''Apple TimeMachine''' ist ziemlich wählerisch, wohin es Backups macht. Ursprünglich sollte das eine lokal angehängte Disk sein, mit der man im Katastrophenfall starten und dann direkt auf das neue Speichermedium rücksichern kann.<br />
<br />
Seit längerer Zeit beherrschen Macs das Starten via Internet bzw. den dort angeschlossenen Apple Servern — sofern man eine funktionierende Internetverbindung hat eine praktische Sache. Damit ist das Thema Starten für Restore vakant.<br />
<br />
== Notwendige Schritte ==<br />
Im Terminal:<br />
* '''Lokales''' Backupimage anlegen. Angelegt wird das im aktuellen Verzeichnis. Im Regelfall ist das das Homeverzeichnis. Die Parameter sollten nach Notwendigkeit angepasst werden.<br />
hdiutil create -size 500G -fs HFS+J -volname 'Backup Volume' Backupvolume.sparsebundle<br />
<br />
* Mounten des Servervolumes (mit ''Cmd-K'') und Kopieren des Images via Finder.<blockquote>'''Achtung!''' Anlegen des Images direkt auf dem Server dauert erheblich länger und legt kein Sparsebundle an, sondern die Datei in voller Größe!</blockquote>Nach dem Kopieren kann die lokale Version gelöscht werden.<br />
<br />
* Image auf dem Server doppelklicken (mounten).<br />
<br />
* Timemachine via Kommandozeile im Terminal anweisen, das gemountete Volume zu benutzen. ''Sudo'' wird nach dem Passwort fragen!<br />
sudo tmutil setdestination /Volumes/'Backup Volume'<br />
<br />
In den TimeMachine Systemeinstellungen bzw. über die Menüleiste kann nun das erste Backup von Hand gestartet werden.<br />
<br />
== Siehe auch ==<br />
* [https://foliovision.com/2010/05/network-backup-apple-timemachine How to create a network backup with Apple’s TimeMachine], FolioVision<br />
<br />
[[Kategorie: Datensicherung]]<br />
[[Kategorie: Mac OS X]]</div>PoChttps://kb.pocnet.net/index.php?title=Apple_TimeMachine_Backup_in_Disk_Image&diff=2867Apple TimeMachine Backup in Disk Image2021-09-12T16:34:05Z<p>PoC: Neu</p>
<hr />
<div>'''Apple TimeMachine''' ist ziemlich wählerisch, wohin es Backups macht. Ursprünglich sollte das eine lokal angehängte Disk sein, mit der man im Katastrophenfall starten und dann direkt auf das neue Speichermedium rücksichern kann.<br />
<br />
Seit längerer Zeit beherrschen Macs das Starten via Internet bzw. den dort angeschlossenen Apple Servern — sofern man eine funktionierende Internetverbindung hat eine praktische Sache. Damit ist das Thema Starten für Restore vakant.<br />
<br />
== Notwendige Schritte ==<br />
Im Terminal:<br />
* Unsupported Volumes anknipsen.<ref>Nicht klar ob das wirklich notwendig ist.</ref><br />
defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1<br />
<br />
* '''Lokales''' Backupimage anlegen, z.&thinsp;B.<br />
hdiutil create -size 500G -fs HFS+J -volname 'Backup Volume' Backupvolume.sparsebundle<br />
<br />
* Mounten des Servervolumes (mit ''Cmd-K'') und Kopieren des Images via Finder.<blockquote>'''Achtung!''' Anlegen des Images direkt auf dem Server dauert erheblich länger und legt kein Sparsebundle an, sondern die Datei in voller Größe!</blockquote>Nach dem Kopieren kann die lokale Version gelöscht werden.<br />
<br />
* Image auf dem Server doppelklicken (mounten).<br />
<br />
* Timemachine via Kommandozeile im Terminal anweisen, das gemountete Volume zu benutzen:<br />
sudo tmutil setdestination /Volumes/'Backup Volume'<br />
<br />
In den TimeMachine Systemeinstellungen bzw. über die Menüleiste kann nun das erste Backup von Hand gestartet werden.<br />
<br />
== Siehe auch ==<br />
* [https://foliovision.com/2010/05/network-backup-apple-timemachine How to create a network backup with Apple’s TimeMachine], FolioVision<br />
<br />
== Fußnoten ==<br />
<references /><br />
<br />
[[Kategorie: Datensicherung]]<br />
[[Kategorie: Mac OS X]]</div>PoChttps://kb.pocnet.net/index.php?title=Zur%C3%BCcksetzen_der_Lizenzinformationen_vom_Microsoft_RDP_Client_f%C3%BCr_Mac_OS_X&diff=2865Zurücksetzen der Lizenzinformationen vom Microsoft RDP Client für Mac OS X2021-08-19T14:45:01Z<p>PoC: Anpassung für Catalina bzw. "Microsoft Remote Desktop" 10.6.8.</p>
<hr />
<div>Bei Änderungen der Terminaldiensteliziensierung von Terminalservern kann es notwendig werden, die '''Lizenzinformationen vom Microsoft RDP Client''' zurück zu setzen. Der Fehler zeigt sich dahingehend, dass ein Fehlercode 259 ausgegeben wird.<br />
<br />
Der Vorgang ist für Windows recht gut beschrieben, für Mac OS X allerdings nicht.<br />
<br />
Am Einfachsten ist es, alle Lic-Informationen im bestehenden Ordner zu löschen, während der Client selbst nicht läuft:<br />
rm "Library/Containers/com.microsoft.rdc.macos/Data/Library/Application Support/Microsoft Remote Desktop/*"<br />
<br />
[[Kategorie:Mac OS X]]<br />
[[Kategorie:Windows]]</div>PoChttps://kb.pocnet.net/index.php?title=Vlans_einfach_erkl%C3%A4rt&diff=2858Vlans einfach erklärt2021-04-19T10:04:42Z<p>PoC: Neu</p>
<hr />
<div>Ein [https://en.wikipedia.org/wiki/Virtual_LAN '''Vlan'''] ist die Definition eines ''virtuellen'' [https://en.wikipedia.org/wiki/Network_segment '''Netzwerk-Segments'''] mittels einer Nummer von 1 - 4096. Technisch realisiert wird dies mit [https://en.wikipedia.org/wiki/EtherType#VLAN_tagging Vlan-Tags], einer (optionalen) Markierung im [https://en.wikipedia.org/wiki/Ethernet_frame#Header Ethernet-Header].<br />
<br />
Vlans kann man sich bildlich vorstellen als eine Möglichkeit, einen [https://en.wikipedia.org/wiki/Network_switch Netzwerk-Switch] in unabhängige Netzwerksegmente zu unterteilen. Man kann z.&thinsp;B. die natürlichen optischen Grenzen der Portblöcke nutzen und einen Aufkleber anbringen: 1-12 = Vlan 1, 2-24 = Vlan 2, oder statt den Vlan-Tags einen logischen Namen anbringen (''Internes Netz'', ''IOT-Geräte'').<br />
<br />
Vlans können auch aus einem Switch "ausgeleitet" werden und über lediglich eine Kabelverbindung diese Vlans auf einem anderen Switch (eines anderen Herstellers) verfügbar machen. Die verwendeten Tags (Nummern) müssen dabei allerdings auf den verwendeten Komponenten übereinstimmen.<br />
<br />
Verschiedene Hersteller verwendenden verschiedene Begriffe für grundlegende Definitionen. Cisco macht es indes erheblich einfacher als alle anderen mir bekannten Hersteller, Vlans zu verstehen.<br />
<br />
== Modus von Switchports ==<br />
Ports werden unterschieden in Vlan-Trunk-Ports und Access-Ports.<br />
<br />
* Ein Access-Port ist stets nur immer einem Vlan gleichzeitig zugewiesen. Jeglicher Datenverkehr über diesen Port findet immer ohne Vlan-Markierung (Tags) statt: So muss das Endgerät kein Vlan können, kann sich aber in einem bestimmten LAN-Segment befinden. Für das Endgerät ist ein Access-Port transparent.<br />
* Ein Vlan-Trunk-Port verbindet z.&thinsp;B. Switches untereinander, welche die definierten virtuellen LAN-Segmente ihrerseits auf Ports anbieten sollen.<br />
<br />
Bei Cisco wird dies so konfiguriert:<br />
interface FastEthernet0/1<br />
switchport mode [access|trunk]<br />
<br />
== Natives Vlan von Vlan-Trunk-Ports ==<br />
Aus Kompatibilitätsgründen ist definiert, dass es ein Default-Vlan gibt (natives Vlan).<br />
* Eingehende Pakete ohne Vlan-Tags werden in dieses Vlan geleitet,<br />
* Ausgehende Pakete von diesem Vlan werden ohne Tag über den Port gesendet.<br />
<br />
Dies ist ohne weitere Konfiguration stets das Vlan 1.<ref>Quelle?</ref> Deswegen funktionieren in 99&thinsp;% aller Fälle Endgeräte auch an einem Vlan-Trunk-Port: Das Endgerät kennt keine Vlan-Tags und ignoriert somit den Traffic auf nicht-nativen Vlans. Da das Default-Vlan meistens das erste eingerichtete LAN-Segment in einem neu eingerichteten Netzwerk ist, sind die Endgeräte auch auf Vlan-Trunk-Ports quasi automatisch diesem ersten Netzwerksegment zugeordnet.<br />
<br />
== Weitere Definitionen ==<br />
* Restriktion, welche Vlans durch einen Port raus und rein dürfen. Per Default ist bei Cisco alles offen (keine entsprechende Cfg-Zeile sichtbar):<br />
interface FastEthernet0/1<br />
switchport trunk allowed vlan <list><br />
<br />
* Ändern des Default-Vlans (statt 1):<br />
interface FastEthernet0/1<br />
switchport trunk native vlan <num><br />
<br />
== Zusammenfassung ==<br />
Manche Hersteller verwässern die strikte Trennung zwischen Access- und Vlan-Trunk-Ports und stellen stattdessen den Anwender vor die Wahl, welche Vlans mit und welche ohne über einen Port gehen sollen. Mehrere Vlans ohne Tags über den gleichen Port ist '''ungültig''' (ein Port soll z.&thinsp;B. für Vlan 1 und 5 untagged sein). Das wird spätestens beim ''Apply'' der Konfiguration angemeckert, anstatt sowas durch die Oberflächenlogik schon von vornherein auszuschließen. Solche Oberflächen machen das Verständnis von Vlans für den engagierten Laien unnötig schwer, verwirren mehr als sie helfen und bringen einen Ballast an weiteren Fachbegriffen mit sich, deren Logik sich auch Experten nicht immer auf Anhieb erschließt. Mit einem virtuellen Wörterbuch z.&thinsp;B. Cisco ↔︎ ''Hersteller'' ist sowas aber üblicherweise relativ gut in den Griff zu bekommen.<br />
<br />
Hat man erstmal die Grundbegriffe verinnerlicht, ist es wirklich extrem simpel:<br />
* Trunk- oder Access-Port?<br />
* Wenn Trunk, dann natives (default) Vlan = 1 (standard) oder doch ein anderes?<br />
* Wenn Trunk, welche Vlan-Tags dürfen passieren (alle oder nur manche)?<br />
<br />
Die größte Herausforderung liegt stets darin, diese drei sehr simplen Festlegungen auf die jeweiligen Bedienoberflächen und Begriffsfestlegungen der verschiedenen Hersteller umzusetzen.<br />
<br />
== Fußnoten ==<br />
<references /><br />
<br />
[[Kategorie:Cisco]]<br />
[[Kategorie:Netzwerk]]<br />
[[Kategorie:Switching]]</div>PoChttps://kb.pocnet.net/index.php?title=Cisco_IOS_Konfigurationsgrundlagen&diff=2857Cisco IOS Konfigurationsgrundlagen2021-04-19T09:12:35Z<p>PoC: +Link</p>
<hr />
<div>Dieser Artikel soll eine Kurzeinweisung in die '''Konfigurationsgrundlagen''' von '''Cisco IOS''' geben. Die vorgestellten Praktiken gelten allerdings nur für hinreichend neue Releases (11 oder neuer).<br />
<br />
== Erstinbetriebnahme ==<br />
Die Grundkonfiguration erfolgt seriell mit den Einstellungen 9600-N-8-1. Die Konsolenschnittstelle ist bis auf wenige Ausnahmen als RJ-45-Steckverbindung ausgeführt. Dazu wird das passende Konfigurationskabel benötigt.<br />
<br />
Ein Router ohne Konfiguration bootet das IOS vom Flashspeicher und versucht auf seine Konfiguration zuzugreifen. Gibt es diese nicht, fragt IOS nach, ob man den Konfigurationsassistenten starten möchte.<br />
<br />
Erscheint stattdessen eine Loginaufforderung, so muss zuerst eine sogenannte ''Password Recovery'' durchgeführt werden, siehe Abschnitt [[#Weblinks|Weblinks]].<br />
<br />
== Struktur ==<br />
Außer am Loginprompt kann der Benutzer jederzeit ein Fragezeichen eingeben, um eine kontextabhängige Hilfe zum jeweiligen Modus zu erhalten. Die Hilfefunktion berücksichtigt auch Kommandos mit mehreren Parametern, sodass der Benutzer jederzeit Kenntnis über die erforderliche Syntax erhalten kann.<br />
<br />
Mit Hilfe der Tabulatortaste können begonnene Kommandos vervollständigt werden, sofern die eingegebene Buchstabenfolge eindeutig ist.<br />
<br />
Die grundlegende Struktur sieht aus wie folgt:<br />
* Prompt<br>→ Login<br />
** Unprivilegierte Kommandozeile<br>→ ''enable''<br />
*** Privilegierte Kommandozeile<br>→ ''configure''<br />
**** Konfigurationsmodus<br>→ ''interface …''<br />
***** Subkontext (Interface, Line, usw.)<br />
***** ← ''exit''<br />
**** ← ''end''<br />
*** ← ''disable''<br />
** ← ''logout''<br />
<br />
Am ''Loginprompt'' muss sich der Benutzer vor dem Zugriff auf die Kommandozeile (Cisco-Sprech: exec) erst authentisieren. Je nach Konfiguration kann der Zugriff auf Adressebene restriktiert sein oder der Login ist benutzerlos (nur mit Passwort) möglich. Ebenso ist es möglich, dass auf der seriellen Konsole keine Authentifizierung konfiguriert wurde, während Zugriffe per Telnet/ssh authentisiert werden müssen. Der Prompt endet in einem Größerzeichen.<br /><br />
Auf dieser Ebene können Benutzer nichtadministrative Aufgaben erledigen, wie z.&thinsp;B. die momentane Exec-Sitzung in eine PPP-Sitzung umwandeln, auf der Kommandozeile mittels ''Ping'' und ''Traceroute'' Netzwerkdiagnosen durchführen oder sich per Telnet/ssh weiterverbinden.<br /><br />
Aus diesem Modus kann der Benutzer mit ''exit'' oder ''logout'' die Sitzung schließen und für einen erneuten Login bereit machen.<br />
<br />
In den ''privilegierten Modus'' gelangt man mit dem ''Enable-Passwort''. Dieses ist in der Konfiguration entweder im Klartext oder als MD5-Hash hinterlegt (<code>enable password</code> bzw. <code>enable secret</code>. Je nach Konfiguration muss kein Enable-Passwort eingegeben werden, um direkt vom Loginprompt in den privilegierten Modus zu gelangen. Der Prompt endet in einer Raute.<br /><br />
Die zwei häufigsten Gründe, in den privilegierten Modus zu wechseln, ist die Ausgabe der Konfiguration oder die Absicht, die Konfiguration zu ändern. Ebenso ist es möglich, mit ''reload'' das Gerät erneut zu starten.<br /><br />
Aus diesem Modus kann der Benutzer mit ''disable'' wieder in den nichtprivilegierten Modus wechseln, oder mit ''exit'', ''logout'', usw. schließen und für einen erneuten Login bereit machen.<br />
<br />
Im privilegierten Modus kann in den Konfigurationsmodus gewechselt werden. Das Kommando erwartet als Parameter eine Konfigurationsquelle. In den allermeisten Fällen ist das ''terminal'', also per Kommandozeileneingabe. Der Prompt ändert sich auf ''(configure)'' vor der Raute.<br /><br />
In diesem Modus können generische Parameter der Konfiguration zur Laufzeit geändert werden.<br /><br />
Aus diesem Modus kann der Benutzer mit ''end'' oder ''exit'' wieder in den ''privilegierten Modus'' wechseln.<br />
<br />
Im Subkontext-Konfigurationsmodus werden spezifische Parameter konfiguriert. Bei Betrachten einer bestehenden Konfiguration ist dies an einer Einrückung der Parameter erkennbar.<br />
<br /><br />
Aus diesem Modus kann der Benutzer mit ''exit'' wieder in den globalen Konfigurationsmodus zurückwechseln oder mit ''end'' zurück in den ''privilegierten Modus''.<br />
<br />
=== Konfiguration ===<br />
Zu beachten ist: Manche Parameter werden bei Änderung überschrieben (z.&thinsp;B. das ''enable-secret'', da es nur eines geben kann). Andere Parameter werden wie eine Liste ergänzt (z.&thinsp;B. ''ntp server''). Das Entfernen von Konfigurationseinstellungen kann in den allermeisten Fällen durch wiederholen der exakten Konfigurationszeile mit einem vorangestellten ''no'' erreicht werden.<br />
<br />
IOS-Geräte haben zwei Konfigurationen:<br />
* ''Running-Config'' ist die derzeit aktive Konfiguration.<br />
* ''Startup-Config'' ist die gespeicherte Konfiguration für den nächsten Bootvorgang.<br />
<br />
Die Ausgabe erfolgt mit ''show'', also<br />
show startup-config<br />
bzw.<br />
show running-config<br />
<br />
Die Konfiguration kann im privilegierten Modus gespeichert werden:<br />
write memory<br />
<br />
Hat man einen Fehler gemacht, kann durch einen Reboot des Gerätes die gespeicherte Konfiguration reaktiviert werden.<br />
reload<br />
<br />
Vor einem Eigentümerwechsel des Gerätes, ist es zweckmäßig, die Konfiguration vorher zu löschen und den Auslieferungszustand damit herzustellen:<br />
erase nvram<br />
<br />
Die Konfiguration der Geräte ist Text. Beim Bootvorgang des Gerätes wird die gespeicherte Konfiguration abgearbeitet, als würde sie per Hand nach und nach eingegeben. Eine Sicherung der Konfiguration kann daher problemlos mit einem Texteditor angefertigt werden.<br />
<br />
== Minimale Konfiguration für Remotezugriff ==<br />
Je nachdem ist es etwas umständlich, ein zurückgesetztes oder neues IOS-Gerät nur seriell konfigurieren zu können. Eine minimale Konfiguration für den Zugriff via Telnet sieht beispielsweise wie folgt aus:<br />
interface VLan1<br />
ip address 192.168.196.100 255.255.255.0<br />
no shutdown<br />
!<br />
ip route 0.0.0.0 0.0.0.0 Vlan1 192.168.196.1<br />
!<br />
enable secret blahblubb<br />
!<br />
line vty 0 4<br />
password blahblubb<br />
!<br />
<br />
Als Interface muss ein Layer-3-Interface genommen werden. Bei einigen Modellen ist ein Switchmodul (mit Layer-2-Interfaces) eingebaut, welches hintendran zu einem Layer-3-VLan-Interface zusammengefasst wird. Falsch machen kann man eigentlich nichts. Wenn man versucht, einem Switchport eine IP-Adresse zu verpassen, antwortet IOS mit einer entsprechenden Meldung auf der Konsole. Eine Übersicht über die vorhandenen Schnittstellen mit ihren Kurznamen liefert ein<br />
show interface description<br />
<br />
== Siehe auch ==<br />
* [[Vlans einfach erklärt]]<br />
<br />
== Weblinks ==<br />
* [http://www.cisco.com/en/US/docs/ios/fundamentals/configuration/guide/12_4/cf_12_4_book.html Cisco.com: Cisco IOS Configuration Fundamentals Configuration Guide] (engl.)<br />
* [http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/products_tech_note09186a00801746e6.shtml Cisco.com: Password Recovery Procedures] (engl.)<br />
<br />
[[Kategorie:Cisco]]</div>PoChttps://kb.pocnet.net/index.php?title=Format_des_Spamassassin_Backup&diff=2839Format des Spamassassin Backup2020-12-25T19:32:37Z<p>PoC: /* T-Teile */ Typo</p>
<hr />
<div>Die '''Backupfunkion von Spamassassin''' schreibt ein tabellarisches '''Dateiformat''' im Klartext, dessen Feldbschreibungen nicht einfach auffindbar sind. Dieses Format soll hier dokumentiert werden.<br />
<br />
== Drei Arten von Zeilen ==<br />
{|class="wikitable"<br />
!Zeile<br />
!DB-Tabelle<br />
|-<br />
|s<br />
|bayes_seen<br />
|-<br />
|t<br />
|bayes_token<br />
|-<br />
|v<br />
|bayes_global_vars<br />
|}<br />
<br />
Die nachfolgenden Informationen variieren je nach Zeilenart.<br />
<br />
----<br />
=== V-Zeile ===<br />
==== Format 1 ====<br />
Line Val. Key<br />
v 3 db_version # this must be the first line!!!<br />
<br />
MariaDB [spamassassin]> select * from bayes_global_vars limit 5;<br />
+----------+-------+<br />
| variable | value |<br />
+----------+-------+<br />
| VERSION | 3 |<br />
+----------+-------+<br />
<br />
==== Format 2 ====<br />
Line Val. Key<br />
v 679734 num_spam<br />
v 606034 num_nonspam<br />
<br />
MariaDB [spamassassin]> select * from bayes_vars limit 5;<br />
+----+--------------+------------+-----------+-------------+-------------+------------------+--------------------+------------------+------------------+<br />
| id | username | spam_count | ham_count | token_count | last_expire | last_atime_delta | last_expire_reduce | oldest_token_age | newest_token_age |<br />
+----+--------------+------------+-----------+-------------+-------------+------------------+--------------------+------------------+------------------+<br />
| 1 | spamassassin | 679734 | 606034 | 5593680 | 1608721482 | 22118400 | 92193 | 1563616942 | 1608898408 |<br />
+----+--------------+------------+-----------+-------------+-------------+------------------+--------------------+------------------+------------------+<br />
<br />
----<br />
=== T-Zeile ===<br />
Line n_spam n_ham atime token<br />
t 0 2 1578062662 a51f87d29e<br />
t 94 333 1606745986 000124aa15<br />
<br />
MariaDB [spamassassin]> select id, hex(token), spam_count, ham_count, atime from bayes_token limit 5;<br />
+----+------------+------------+-----------+------------+<br />
| id | hex(token) | spam_count | ham_count | atime |<br />
+----+------------+------------+-----------+------------+<br />
| 1 | A51F87D29E | 0 | 2 | 1578062662 |<br />
| 1 | 000124AA15 | 94 | 333 | 1606745986 |<br />
| 1 | 00014C46DB | 147 | 976 | 1608828621 |<br />
| 1 | AEAB11EE46 | 0 | 3 | 1575190834 |<br />
| 1 | 00031FFB07 | 38 | 2485 | 1608723281 |<br />
+----+------------+------------+-----------+------------+<br />
<br />
Bitwert bleibt gleich auf OS/400!!<br />
<br />
....+....1....+....2....+....3....+....4....+....5....+....6....+....7....+..<br />
ID HEX ( TOKEN ) SPAM_COUNT HAM_COUNT ATIME <br />
1 000124AA15 94 333 1.606.745.986 <br />
<br />
----<br />
<br />
=== S-Zeile ===<br />
Line flag msgid<br />
s h af1eced4f05c75d52f3b0539e6da1304f7c2769c@sa_generated<br />
s s eea1310bdc1e66c30af31619ac880d58195436af@sa_generated<br />
<br />
MariaDB [spamassassin]> select * from bayes_seen limit 5;<br />
+----+-------------------------------------------------------+------+<br />
| id | msgid | flag |<br />
+----+-------------------------------------------------------+------+<br />
| 1 | af1eced4f05c75d52f3b0539e6da1304f7c2769c@sa_generated | h |<br />
| 1 | eea1310bdc1e66c30af31619ac880d58195436af@sa_generated | s |<br />
| 1 | 4e4f77c01592c063322a5f9197d83ac6f3be9a91@sa_generated | h |<br />
| 1 | fdd9c5a887bb906a683163fa36052ebdc0a5f483@sa_generated | h |<br />
| 1 | b53e253ab3c54d4bb29891bd4d7e5e2b18b3c9c7@sa_generated | h |<br />
+----+-------------------------------------------------------+------+<br />
<br />
[[Kategorie:Linux]]<br />
[[Kategorie:Datenbank]]<br />
[[Kategorie:Software]]</div>PoC