Linupedia.org - Benutzerbeiträge [de]

MosNis Automatisierung/Installationsautomatisierung von Windows mit Unattended

2007-06-20T12:00:28Z

Rolle:

{{UnderConstruction}}

Die Installation von Windows, hier entweder 2000 oder XP, teilt sich in drei Abschnitte, das Starten des zu installierenden Computers mittels BootCD oder Bootdisketten oder Neboot, die Beantwortung wesentlicher Fragen für die Windowsinstallation sowie eventuell die Auswahl zusätzlicher Software und zuletzt die automatisierte Installation gewünschter Software und die Einrichtung des Systems.
Das Ganze basiert auf den Perlskripten von [unattended.sf.net]. Dort findet sich auch eine ausführliche, leider nur englischsprachige, Hilfe mit Beispielen.
Da bei mir nur ältere Rechner zum Einsatz kamen, die größtenteils nicht per PXE booten können, habe ich mit der LinuxbootCD von unattended gearbeitet. Die hat gegenüber den DOS-Disketten bzw. der DOS-CD den Vorteil, daß die Hardwareunterstützung für Netzwerkchips besser und einfacher integriert ist.

== Vorarbeiten ==

Wir benötigen einen lauffähigen DHCP-Server wie für den Rest von MosNis auch. Dazu kommt ein DNS-Server, der den Namen 'ntinstall' immer auf den Installationsserver auflöst. Ich habe das mit dem kleinen Server 'dnsmasq' mittels der Option
address=/ntinstall/AAA.BBB.CCC.DDD
erledigt. Nun muß noch der DHCP-Server den DNS-Server bekanntmachen:
option domain-name-servers AAA.BBB.CCC.DDD;
Sollte man nur einen Windowsinstallationsserver aufsetzen wollen, kann man dnsmasq auch gleich als DHCP-Server betreiben. Unter openSuSE 10.2 funktioniert das bestens, unter Fedora Core 6 hatte ich Probleme mit den Besonderheiten von dnsmasq, die zu lösen zu lange gedauert hätte. Gehen müßte es aber eigentlich.
Sodann erstellen wir eine Freigabe im Sambaserver mit Namen 'install':
[install]
# Beschreibung in der Netzwerkumgebung
comment = Unattended
# verhindert schreibende Zugriffe auf die Freigabe
writable = no
# erlaubt mehrere gleichzeitige Zugriffe auf die Dateien
locking = no
# absoluter Pfad zum freigegebenen Verzeichnis
path = /samba/unattended/install
# erlaubt Gastzugriffe auf die Freigabe
guest ok = yes
Zuletzt müssen wir unseren Sambaserver noch zum WINS-Server machen, da es einen Moment in der Windowsinstallation gibt, zu dem die Namensauflösung per NetBIOS stattfindet und nicht per DNS. Dazu tragen wir in die smb.conf folgende Zeile ein:
wins support = yes
In die dhcpd.conf:
option netbios-name-servers AAA.BBB.CCC.DDD;
In die /etc/hosts:
AAA.BBB.CCC.DDD ntinstall
Dabei ist es unerheblich, ob die IP in der /etc/hosts schon vergeben ist, eine zweite Definition hat sich hier nicht als störend erwiesen.
Nun besorgen wir uns die Pakete von unattended und entpacken die entsprechend der dortigen Anleitung. Unter /PFAD/install/scripts finden wir dann viele Batchdateien, von denen wir erst einmal alle löschen, die wir nicht benötigen. Weitere Batchfiles sind auf den unattended-Seiten verlinkt, findet man die benötigten dort nicht, muß man sie selber bauen. Dazu später mehr.
Unter /PFAD/install/os legen wir nun zwei Verzeichnisse beliebigen Namens an, am schönsten, da kurz und prägnant, '200' und 'XP'. Dort hinein kopieren wir jeweils das 'i386' Verzeichnis von den Windowsscheiben.
Jetzt sollten wir erst einmal alles haben, was wir benötigen.

==Definitionen für unattended==

Jetzt müssen wir definieren, wie die Windowsinstallation stattfinden soll. Dazu gibt es die Datei /PFAD/install/lib/unattend.txt. In dieser können beinahe beliebig viele Parameter vordefiniert werden. Als Anhaltspunkt die von mir verwandte:
; General user information
[UserData]
; Definiert den Namen des Anwenders
FullName="admin"
; Definiert dessen Organisation
OrgName="XYZ"
; Definiert den Namen des zu installierenden Rechner, hier auskommentiert, damit bei der Installation eine Abfrage danach kommt
; ComputerName=lurinstall
; Lizenznummer von Windows XP
ProductKey=12345-67890-12345-67890-12345

[GuiUnattended]
; See <http://unattended.sourceforge.net/timezones.html>
; Definiert die Zeitzone des zu installiernden Rechners
TimeZone=110
; überspringt die Regionenabfrage
OEMSkipRegional=1
; übersprint den Willkommensbildschirm
OemSkipWelcome=1
; Definiert das Administratorenpasswort
AdminPassword=XYZ

[Identification]
; Beitritt zu folgender Arbeitsgruppe
JoinWorkgroup=XYZ

[Shell]
; Use classic start menu
DefaultStartPanelOff=Yes
; Use classic visual style
DefaultThemesOff=Yes

[Unattended]
; ignoriert die Nichtsignierung von Treibern
DriverSigningPolicy=Ignore
UnattendMode=DefaultHide
; konvertiert das Dateisystem zu NTFS
FileSystem=ConvertNTFS
; erweitert dasselbe auf die gewünschte Größe
ExtendOemPartition=1
; unterdrückt die EULA-Annahmeabfrage
OemSkipEula=Yes
OemPreinstall=Yes
; Needed for XP - see <http://support.microsoft.com/?kbid=294801>.
UnattendSwitch=Yes

[Components]
; Install IIS by default
iis_common=Off
iis_inetmgr=Off
iis_www=Off
; Docs suggest iis_pwmgr only works on Win2k, but include it
; anyway
iis_pwmgr=Off
; Include docs
iis_doc=Off

[Data]
AutoPartition=1
MsDosInitiated="0"
UnattendedInstall=Yes

[Display]
BitsPerPel=32
Xresolution=1024
YResolution=768
Vrefresh=75

[LicenseFilePrintData]
AutoMode=PerServer
AutoUsers=5

[Networking]
InstallDefaultComponents=Yes

[NetOptionalComponents]
; Install Print Services for UNIX
; auskommentiert
;LPDSVC=1

[_meta]
;top=base.bat
; definiert den Zeitserver
ntp_servers="ntp1.fau.de"

Mit dem Suchbegriff 'unattend.txt' wird man auf der Microsoftheimatseite auch noch mehr mögliche Parameter finden, normalerweise genügen die Beispiele von [unattend.sf.net] aber.
Für Windows 2000 habe ich keinen Produktschlüssel angegeben, da wir das hier nicht benötigen für die Unternehmensversion.
Grundsätzlich gilt: Alles, was nicht in der unattend.txt definiert ist, wird während der Installation abgefragt, insbesondere eben Produktschlüssel, Rechnernamen, Adminpasswort...

==zusätzliche Programme==
Ein blankes Windows ist zum Arbeiten nur bedingt nutzbar, es müssen also noch Anwendungen her. Leider hat Windows aber keine Paketverwaltung, sondern jede Anbieterin von Software bäckt ihre eigenen Brötchen. Es gibt verschiedenste Formate, wie Software daherkommen kann: Als .msi, als Install Shield Wizard.... .msi-Routinen kann man normalerweise per
BEFEHL /?
eine Liste der Optionen entlocken. Wie das bei den anderen Installationsroutinen geht, falls die Anbieterin der Software dieses Feature ausnahmsweise einmal implementiert hat, ist auf der Heimatseite von unattended schön zusammengefaßt. Auf jeden Fall bietet es sich an, ein Testwindows herzunehmen und jedes einzelne Programm auszuprobieren, bis man die optimalen Optionen gefunden hat. So gibt es etwa bei InstallShield einen Schalter '/r', mit dem alle Eingaben in der Installationsmaske protokolliert werden in 'c:\windows\install.iss'. Kopiert man diese Datei in das Verzeichnis mit der 'setup.exe', so läuft mit dem Schalter '/s' die Installation danach unbeaufsichtigt genau so ab, wie man sie vorher aufgenommen hat.
Ziel dieser ganzen Aktion ist dann jeweils ein eigenes Batchfile pro Programm, das den notwendigen Installationsbefehl inklusive Parametern enthält.

==Fallstricke==

Hier lauern aber auch einige Fallstricke. So gibt es etwa Installationsroutinen, die in einem selbstentpackenden ZIP-File stecken und denen man folglich keine Parameter mitgeben kann. Diese müssen erst entpackt werden und dann können der eigentlichen Routine Parameter mitgegeben werden. Als Beispiele seien hier Ghostscript, FreePDFXP, OpenOffice.org und der HP Install Network Printer Wizard.
Eine weitere mögliche Gemeinheit sind abzunickende EULAs. Besonders lästig natürlich bei Kommandozeilentools, die eine grafische EULA darstellen, die auch nicht per Schalter zu unterdrücken ist. Wenn man Glück hat, dann gibt es eine Option '/accepteula' oder Ähnliches. Hat man wie z.B. bei Pagedefrag von Sysinternals, jetzt Microsoft, Pech, dann hilft nur, das Programm einmal auf einem Testwindows zu installieren, den Registrykey, der die EULA-Annahme bestätigt zu exportieren und ihn vor Installation des Programmes per 'regedit /s SCHLÜSSEL' in das neue System zu importieren.

==Starten des Computers==

MosNis Automatisierung/Installationsautomatisierung von Windows mit Unattended

2007-06-18T11:05:40Z

Rolle:

MosNis Automatisierung/Installationsautomatisierung von Windows mit Unattended

2007-06-18T09:46:26Z

Rolle:

MosNis Automatisierung/Installationsautomatisierung von Windows mit Unattended

2007-06-18T09:35:33Z

Rolle:

2007-01-02T13:00:48Z

Rolle: /* SuSE 10.0 32 Bit */

== SuSE 10.0 32 Bit==

- Wir modifizieren die dhcpd.conf wie im LTSP-Wiki beschrieben.

''Modify your dhcpd.conf''
''If you're using assigned addressing (i.e. you have host {} entries), make sure you're specifying: use-host-decl-names on; in the dhcpd.conf section where you're specifying the hosts. For dynamic host assignment, you'll want: get-lease-hostnames true; IMPORTANT: The two settings are exclusive, so if you've got use-host-decl-names turned on globally, you're going to have to turn it off in the dynamic section of the dhcpd.conf file. Remember to restart your dhcpd server after modifying the file.''

Wichtig ist es, daß Step 9 des Troubleshootings des Wikis wirklich fehlerfrei ist, eventuell muß man die Zeile 'option domain name....' aus der /etc/dhcpd.conf löschen.

- Wir installieren FUSE per

''apt install fuse''

Es befindet sich im Repository 'packman'. Falls wir kein APT nutzen, ziehen wir uns das RPM direkt von http://packman.iu-bremen.de/suse/10.0/i586/ und installieren es per

''rpm -i DATEINAME''

- Dann führen wir

''modprobe fuse''

als root durch und kontrollieren den Erfolg per

''lsmod''

Taucht dort fuse auf, ist alles in Ordnung. Damit das FUSE-Modul bei jedem Start des Servers automatisch eingebunden wird, öffnen wir YaST->System->Editor für /etc/sysconfig-Dateien->System->Kernel->MODULES_LOADED_ON_BOOT und tragen dort 'fuse' ein.

- Dann installieren wir perl-X11-Protocol-VERSION.noarch.rpm von [ftp://ftp4.gwdg.de/pub/opensuse/repositories/home%3A/rbos/SL-10.0_i586/noarch/].

- Als nächstes laden wir uns von [ftp://ftp.gwdg.de/pub/opensuse/repositories/home%3A/rbos/SL-10.0_i586/i586/]ltsp-server-pkg-VERSION.i586.rpm herunter und installieren es per

''rpm -i PAKETNAME''

- Sodann schreiben wir in die allgemeine Sektion der lts.conf

''LOCAL_STORAGE = Y''

- Fehlersuche gemäß des Wikis.

== SuSE 10.2 32 Bit==
SuSE 10.2 bringt fuse schon von Haus aus mit, man muß es also höchstens mit YaST nachinstallieren. Ansonsten funktioniert das ganze wie bei 10.0, man muß eben nur die Pfade zum richtigen Repository von suser-rbos einpflegen.

== SuSE 9.3 und 10.1 32 Bit==
Hier gilt das gleiche wie für 10.0, man muß eben nur die Pfade zum richtigen Repository von suser-rbos einpflegen.

== 64 Bit ==
Das habe ich noch nicht getestet. Fühlt Euch frei das zu tun und Eure Erfahrungen hier einzupflegen.

Rolle

[[Category:LTSP]]

2006-11-17T20:14:45Z

Rolle:

In letzter Zeit taucht häufiger das Problem auf, daß Menschen ungewollt unter KDE (oder anderen Oberflächen) den Gnomedesktop vor sich haben. Das liegt dann daran, daß sie den Nautilus ohne die notwendigen optionen gestartet haben. Ohne Optionen startet Nautilus den Gnomedesktop gleich mit. Um nur die Dateimanagerfunktion z.B. zu nutzen, muß die Befehlszeile wie folgt lauten:
nautilus --no-desktop
Nähere Hilfe gibt die Hilfe von Nautilus unter
nautilus --help

Um das Problem dann zu beheben muß der laufende Nautilusprozeß gekillt werden. Ein Neustart von KDE genügt hier meist nicht, da dieses standardmäßig die letzte Sitzung wiederherstellt, also auch den Nautilus wieder startet. Deshalb muß man den Prozeß von Hand killen. Dazu muß man erst einmal die Prozeßnummer herausfinden mit folgendem Befehl:
ps -A | grep nautilus
Die Ausgabe sieht dann in etwa so aus:
7384 pts/1 00:00:01 nautilus
Interessant ist hier dann die Prozeßnummer am Anfang der Ausgabe. Mit
kill PROZESSNUMMER
kann man den Nautilus dann beenden, wobei PROZESSNUMMER eben durch die Zahl am Anfang der Ausgabe ersetzt werden muß. Danach sollte der Desktop wieder wie gewohnt und gewünscht ausschauen.

[[Category:Desktop Enviroments und Windowmanager]]

2006-08-25T21:06:25Z

Rolle:

Mit bestem Dank an id3pr.

'''0)''' Allg: Man muss als erstes normal einen Vncserver über die Konsole starten und ein Passwort festlegen. Dann den vncserver wieder schließen.

'''1)''' Man schreibe sich ein Skript (einfach folgenden Quelltext in eine leere Datei kopieren und sie "vncserver" nennen)

#!/bin/bash
#
# chkconfig: - 91 35
# description: Starts and stops vncserver. \
# used to provide remote X administration services.

# Source function library.
. /etc/init.d/functions

# Source networking configuration.
. /etc/sysconfig/network

# Check that networking is up.
[ ${NETWORKING} = "no" ] && exit 0

VNCSERVERS=""
[ -f /etc/sysconfig/vncservers ] && . /etc/sysconfig/vncservers

prog=$"VNC server"

start() {
echo -n $"Starting $prog: "
ulimit -S -c 0 >/dev/null 2>&1
RETVAL=0
for display in ${VNCSERVERS}
do
echo -n "${display} "
unset BASH_ENV ENV
initlog $INITLOG_ARGS -c \
"su ${display##*:} -l -c \"cd ~${display##*:} && [ -f .vnc/passwd ] && vncserver :${display%%:*}\""
RETVAL=$?
[ "$RETVAL" -ne 0 ] && break
done
[ "$RETVAL" -eq 0 ] && success $"vncserver startup" || \
failure $"vncserver start"
echo
[ "$RETVAL" -eq 0 ] && touch /var/lock/subsys/vncserver
}

stop() {
echo -n $"Shutting down $prog: "
for display in ${VNCSERVERS}
do
echo -n "${display} "
unset BASH_ENV ENV
initlog $INITLOG_ARGS -c \
"su ${display##*:} -c \"vncserver -kill :${display%%:*}\" >/dev/null 2>&1"
done
RETVAL=$?
[ "$RETVAL" -eq 0 ] && success $"vncserver shutdown" || \
failure $"vncserver shutdown"
echo
[ "$RETVAL" -eq 0 ] && rm -f /var/lock/subsys/vncserver
}

# See how we were called.
case "$1" in
start)
start
;;
stop)
stop
;;
restart|reload)
stop
sleep 1
start
;;
condrestart)
if [ -f /var/lock/subsys/vncserver ]; then
stop
start
fi
;;
status)
status Xvnc
;;
*)
echo $"Usage: $0 {start|stop|restart|condrestart|status}"
exit 1
esac

'''2)''' diese Datei speichert man im Verzeichnis "/etc/init.d/"

'''3)''' die Datei, genauergesagt das Script, muss ausfühbar sein. Also:

"chmod +x /etc/init.d/vncserver"

'''4)''' das script soll in den richtigen runlevel um automatisch zu starten. Also:

"chkconfig --level 5 vncserver on"
"chkconfig --add vncserver"

'''5)''' Man editiert die Datei "/etc/sysconfig/vncservers"

Contents of /etc/sysconfig/vncservers:

# The VNCSERVERS variable is a list of display:user pairs.
#
# Uncomment the line below to start a VNC server on display :1
# as my 'myusername' (adjust this to your own). You will also
# need to set a VNC password; run 'man vncpasswd' to see how
# to do that.
#
# DO NOT RUN THIS SERVICE if your local area network is
# untrusted! For a secure way of using VNC, see
# URL:http://www.uk.research.att.com/vnc/sshvnc.html.

# VNCSERVERS="1:myusername"
VNCSERVERS="1:bob 2:sally 3:jim"

Logischer Weise muss man anstatt "bob", "sally" und "jim" den Namen des eigenen Nutzers oder der Nutzerin angeben.

'''6)''' rebooten

'''7)''' have a lot of fun

[[Category:grafische Fernsteuerungen]]

Freigabe von screen 0 per VNC mit x11vnc

2006-08-25T21:05:53Z

Rolle:

VNC Server

2006-08-25T21:05:21Z

Rolle:

Im Folgenden möchte ich einmal die vielen verschiedenen Möglichkeiten erläutern, wie man einen Rechner per VNC von außen zugreifbar machen kann. Ich beziehe mich dabei auf ein SuSE Linux 9.3 System. Zumindest teilweise müßten die Anleitungen aber auch auf anderen Linuxen funtionieren.

'''Entscheidungshilfe'''
Die unten beschriebenen Methoden decken jeweils einen anderen Anwendungsfall ab.
Methoden 1 und 2 starten für jeden Menschen, der sich per VNC verbindet eine neue Sitzung, die auch nach dem Abmelden wieder stirbt. Es ist also damit nicht möglich, ein grafisches Programm zu starten, sich abzumelden und dabei das Programm weiterlaufen zu lassen.
Methoden 3 bis 7 ermöglichen genau das, unterscheiden sich nur im Grad der Automation, oder darin, ob auf eine existierende Oberfläche einer schon am VNC-Server lokal angemeldeten Nutzerin zugegriffen werden kann oder ob eine dauerhafte aber separate Oberfläche gestartet wird. So werden wohl Methoden 5, 6 und 7 zu wählen sein, falls beabsichtigt ist, lokalen Nutzerinnen per VNC Hilfestellung leisten zu wollen, Methoden 3 und 4 sind eher tauglich, um mal eben auf dem VNC-Server ein Programm zu starten oder diesen zu administrieren.
Die Methoden 5 bis 7 setzen voraus, daß der VNC-Server dauerhaft im Runlevel 5 läuft bzw. sogar jemand angemeldet ist, Methoden 1 bis 4 funktionieren auch auf einem Server im Runlevel 3.

'''Methode 1:'''
Im YaST gibt es unter 'Netzwerkdienste' den Punkt 'Administration von einem entfernten Rechner'. Das ist etwas mißverständlich, da man damit den Rechner nicht nur administrieren kann, sondern auch den Zugang per VNC auf den Ports 5901 (VNC) und 5801 (VNC über Browser) freischaltet. Öffnet den Unterpunkt und wählt 'Verwaltung via entfernten Rechner (remote) erlauben' aus, beenden. Die folgende Meldung fordert Euch dazu auf, den Befehl 'rcxdm restart' auszuführen. Bevor Ihr das macht, öffnet noch die Datei /etc/opt/kde3/share/config/kdm/kdmrc mit root-Rechten in einem Editor Eurer Wahl und ändert ziemlich weit unten den Wert 'Enable=false' unter dem Punkt [Xdmcp] auf 'Enable=true'. Wechselt jetzt per Strg-Alt-F1 auf die Konsole, meldet Euch als root an und gebt 'rcxdm restart' ein.
Nun müßte es Euch möglich sein, per VNC auf den Port 5901 oder per Browser auf den Port 5801 Eures Rechners zuzugreifen. Es sollte die normale Anmeldemaske erscheinen. Wichtig: Natürlich muß der VNC-Server im Runlevel 5 laufen, da es sonst keinen laufenden X-Server gibt, mit dem man sich verbinden kann.

'''Methode 2:'''
Im YaST gibt es unter 'Netzwerkdienste' den Punkt 'Netzwerkdienste (xinetd)'. Öffnet diesen und klickt auf 'Aktivieren'. In der Mitte des Fensters könnt Ihr jetzt Dienste auswählen, die per xinetd gestartet werden können. Nun könnt Ihr einen oder alle der Dienste namens 'vnc' und 'vnchttpd' auswählen. Sie unterscheiden sich in der verwendeten Auflösung. vnc1 lauscht auf Port 5901 und liefert eine Auflösung von 1024x768, vnc2 auf Port 5902 mit einer Auflösung von 1280x1024 und vnc3 auf Port 5903 mit einer Auflösung von 1600x1200. Entsprechende Auflösungen liefern vnchttpd1 bis vnchttpd3 auf den Ports 5801 bis 5803.
Jetzt noch wie oben die kdmrc editieren und 'rcxdm restart' ausführen. Das Ergebnis sollte das selbe sein wie oben. Wichtig: Natürlich muß der VNC-Server im Runlevel 5 laufen, da es sonst keinen laufenden X-Server gibt, mit dem man sich verbinden kann.

'''Methode 3:'''
Falls Ihr nicht grundsätzlich den Zugriff per VNC erlauben wollt, gibt es auch die Möglichkeit, von Fall zu Fall den VNCServer von Hand zu starten. Dazu kann jede Benutzerin einen vncserver per 'vncserver' starten. Es folgt eine Ausgabe 'New 'X' desktop is RECHNERNAME:ZAHL'. '5900+ZAHL' ist dann der Port, auf dem der VNCServer lauscht und 'ZAHL' die entsprechende Displaynummer. Den Port kann man auch selbst festlegen durch den Befehl 'vncserver :ZAHL'. Beim ersten Start wird das Setzen eines Passwortes verlangt. Das ist wichtig, da sonst jedermann ohne Passwort Zugriff auf den Rechner hat, wenn der VNCServer läuft.
Grundsätzlich unterscheidet sich das Ergebnis von Methode 1 und 2 dadurch, daß hier keine Anmeldemaske erscheint, sondern nur das VNC-Passwort abgefragt wird und dann ein X-Desktop derjenigen Benutzerin erscheint, die den VNCServer gestartet hat.
Standardmäßig ist bei SuSE der TWM als Windowmanager eingestellt. Außer diesem startet nur ein X-Terminal. Wem das zu arm ist, der kann das in der Datei ~/.vnc/xstartup umstellen. Wichtig ist hierbei, das '&' am Ende jeder Zeile nicht zu vergessen. KDE z.B. kann man dadurch starten, daß man 'twm' durch 'startkde' ersetzt, bei XFCE ist es 'startxfce4', bei Gnome 'gnome', bei Openbox 'openbox, etc.. Das X-Terminal kann man per Auskommentierung oder Löschen der entsprechenden Zeile unterdrücken. 'xsetroot' setzt die Hintergrundfarbe und ist auch nicht wichtig. Die Auflösung ist die Eures eigenen Desktops.
Beenden könnt Ihr den VNCServer mittels 'vncserver -kill :ZAHL'

'''Methode 4:'''
Methode 3 ließe sich auch automatisieren. z.B. durch einen Eintrag in die .profile der jeweiligen Nutzerin.

'''Methode 5:'''
KDE bringt eine eigene VNC-Freigabe mit, mit der der momentane KDE-Desktop freigegeben werden kann. Dazu muß das Paket
'kdenetwork3-vnc' installiert sein. Startet das Kontrollzentrum, wählt den Punkt 'Internet & Netzwerk' und darunter 'Arbeitsfläche freigeben' aus. Nun könnt Ihr auswählen, ob Ihr Euren Desktop standardmäßig freigebt oder nur auf Einladung hin, ob Ihr vor einer Verbindung gefragt werden wollt und noch einiges mehr. Die Optionen sind eigentlich ziemlich selbsterklärend. Der VNCServer lauscht auf Port 5900.

'''Methode 6:'''
Auch Gnome bringt eine eigene Desktopfreigabe mit. Dazu muß das Paket 'vino' installiert sein. Die Einstellungen finden sich hier etwas versteckt im 'Gnome Configuration Editor'. Wählt dort unter 'desktop' 'remote access' aus. Einfach 'enabled' anhaken. Die Dokumentation zu den einzelnen Schlüsseln ist selbsterklärend. Vino lauscht auf Port 5900.

'''Methode 7 (Dank an hep83):'''
Yast-Kontrollzentrum/Hardware/Grafikkarte und Monitor/
dort auf "ändern" klicken. (oder direkt Sax2)
Dann gibts da einen Unterpunkt (Zugriffskontrolle-VNC), wo man das VNC Protokoll aktivieren kann. Nach nem Neustart der grafischen Oberfläche läufts perfekt. In VNC einfach per IP oder Name einloggen, ohne Portangabe - nimmt automatisch Port 5900. Der Vorteil dieser Methode ist der, daß der aktuelle Desktop angezeigt wird, ohne von Gnome oder KDE abhängig zu sein.

'''Firewall:'''
Für alle hier vorgestellten Methoden muß natürlich in der SuSEFirewall2 oder einer anderen verwandten Firewall der oder die entsprechende(n) Port(s) freigegeben werden.
Für das Freischalten in der SuSEFirewall2 geht man folgendermaßen vor. Startet YaST, wählt 'Sicherheit und Benutzer', darunter 'Firewall' aus. Im Unterpunkt 'Erlaubte Dienste' markiert Ihr jetzt die Zone, in der Ihr den VNCServer freischalten wollt und wählt 'Erweitert' aus. Hier schreibt Ihr nun in die Zeile 'TCP-Ports' alle Ports durch Leerzeichen getrennt hinein, die Ihr freigeben wollt.

'''Verbindung zum Server:'''
Im Allgemeinen kann man sich in einem VNC-Viewer per SERVERNAME:DISPLAYNUMMER oder SERVERNAME::PORT verbinden. Für Port 5900 genügt auch SERVERNAME alleine. In einem Browser verwendet man SERVERNAME:PORT.

'''Fehlersuche:'''
Im Folgenden liste ich mal ein paar Anhaltspunkte auf, wo man suchen kann, falls es mal nicht klappt. Natürlich sind nicht alle Anhaltspunkte für alle Methoden einschlägig.
- Es erscheint nur ein grauer Bildschirm: kdmrc editiert?, xstartup editiert?
- Es kommt gar keine Verbindung zustande: Firewalls richtig eingestellt (Server und Client)?, funtioniert die Namensauflösung?, xinetd auf Server gestartet?

'''Absicherung der VNC-Verbindung per SSH-Tunnel:'''
Das Problem bei VNC-Verbindungen ist, daß sie unverschlüsselt sind. Das mag im heimischen LAN kein Problem sein, jedoch schon beim heimischen WLAN und spätestens bei einer Verbindung über das Internet wird es eines. Der unverschlüsselte Verkehr kann abgehört werden und niemand möchte, daß seine VNC-Server plötzlich von jemand Böswilligen gesteuert werden. Deshalb ist es sinnvoll, außerhalb des eigenen LANs die VNC-Verbindung per SSH-Tunnel zu verschlüsseln. So spart man sich außerdem, die VNC-Ports in der Firewall freigeben zu müssen.
Das Vorgehen ist folgendermaßen: Auf dem VNC-Server muß ein SSH-Server laufen und in der Firewall der entsprechende Port freigegeben sein (standardmäßig Port 22). Dann öffnet man ein X-Terminal seiner Wahl und gibt folgendes ein:

''ssh -l USERNAME_AUF_SSH-SERVER -C -L PORT_AUF CLIENT:VNC-SERVER:PORT_AUF_SERVER SSH-SERVER''

Danach kann man sich mit einem VNC-Viewer nach localhost::PORT_AUF_CLIENT verbinden (geht auch mit der Displaynummer, dann nur mit einem Doppelpunkt).

''Beispiel: ssh -l tux -C -L 5901:pinguin.antarktis.de:5901 pinguin.antarktis.de; danach vncviewer localhost::5901 oder vncviewer:1.''

Nähere Erläuterungen zu SSH-Tunnels gibt auch http://www.linux-club.de/viewtopic.php?t=18914.
Für SSH-Tunnel von Windowsrechnern aus empfehle ich Putty zu verwenden. Ein howto findet sich hier: http://www.netzmafia.de/skripten/internet/putty-tunnel.html

Anmerkungen, Verbesserungen und Nachfragen bitte unter [http://www.linux-club.de/ftopic37443.html Diskussion zum VNC-Howto] posten.

Rolle

[[Category:grafische Fernsteuerungen]]

Kategorie:Grafische Fernsteuerungen

2006-08-25T21:04:20Z

Rolle:

Viele verschiedene Möglichkeiten, einen Linuxrechner aus der Ferne per Klickibunti zu bedienen.