Στο Τμήμα μας έχουμε έναν ltsp server που δίνει teminal service σε εσωτερικό δίκτυο με δεύτερη κάρτα δικτύου, αλλά θέλουμε να υποστηρίξουμε και μερικά τερματικά που βρίσκονται σε κανονικό δίκτυο (όχι στο εσωτερικό δίκτυο) και που παίρνουν dhcp από έναν windows dhcp server.
Είχαμε ένα πρόβλημα με αυτά τα τερματικά διότι ο server δεν επέτρεπε το mount του image,
έβγαζε « nbdrootd connection refused <client-IP> », πρόβλημα το οποίο λύθηκε με τη βοήθεια του Άλκη Γεωργόπουλου, αφού ξεχάσαμε να προσθέσουμε τις εξωτερικές IP στο /etc/hosts.allow
Τώρα τα τερματικά στις εξωτερικές IP ξεκινούν κανονικά και κάνουν κανονικά login στον server.
Όμως συμβαίνει το εξής: Στην οθόνη εισόδου, στον ldm, σε αυτά τα τερματικά το μενού των επιλογών (κάτω αριστερά) είναι σχεδόν άδειο. Συγκεκριμμένα, τόσο η επιλογή γλώσσας όσο και η επιλογή του session έχουν μόνο την «Προεπιλογή». Στο session υπάρχει και ένα failsafe.
Αντιθέτως, στα τερματικά που ξεκινούν και βρίσκονται στο εσωτερικό 10.0.0.x δίκτυο, στην επιλογή του session υπάρχουν διάφορα (Gnome, KDE, xfce, κλπ).
Πώς μπορεί να διορθωθεί αυτό;
Ευχαριστώ πολύ.
Λογικά πρέπει να είναι το ίδιο πρόβλημα, αλλά για τον ldminfod αυτή τη φορά.
Χρησιμοποιήσατε τα sch-scripts (http://wiki.ubuntu-gr.org/sch-scripts) για την εγκατάσταση; Να οι σχετικές καταχωρήσεις που βάζουν στο /etc/hosts.allow:
ldminfod: 127., 10., 192.168., 172.16.-172.31., 169.254., 150.140.14.: keepalive
nbdswapd: 127., 10., 192.168., 172.16.-172.31., 169.254., 150.140.14.: keepalive
nbdrootd: 127., 10., 192.168., 172.16.-172.31., 169.254., 150.140.14.: keepalive
sch-server: 127., 10., 192.168., 172.16.-172.31., 169.254., 150.140.14.: keepalive
Δεν φαίνεται να είναι αυτό το πρόβλημα:
[root@myria ~]# cat /etc/hosts.allow
ldminfod: 127., 10., 192.168., 172.16.-172.31., 169.254., 195.251.161.: keepalive
nbdswapd: 127., 10., 192.168., 172.16.-172.31., 169.254., 195.251.161.: keepalive
nbdrootd: 127., 10., 192.168., 172.16.-172.31., 169.254., 195.251.161.: keepalive
sch-server: 127., 10., 192.168., 172.16.-172.31., 169.254., 195.251.161.: keepalive
[root@myria ~]#
Επίσης στο daemon.log βλέπω:
[root@myria log]# grep -e 195.251.161.71 daemon.log
Jan 14 10:57:21 myria nbdrootd[26626]: connect from 195.251.161.71 (195.251.161.71)
Jan 14 10:57:21 myria nbd_server[26626]: connect from 195.251.161.71, assigned file is /opt/ltsp/images/i386.img
Jan 14 10:57:37 myria ldminfod[26720]: connect from 195.251.161.71 (195.251.161.71)
Jan 14 10:57:43 myria nbdrootd[26748]: connect from 195.251.161.71 (195.251.161.71)
Jan 14 10:57:43 myria nbd_server[26748]: connect from 195.251.161.71, assigned file is /opt/ltsp/images/i386.img
[root@myria log]#
Άρα συνδεεται ο ldminfod
Πράγματι η εγκατάσταση έγινε με τα sch-scripts.
Θα χρειαστούν λίγες περισσότερες πληροφορίες για να δούμε τι δεν πάει καλά. Βολικό θα ήταν και το IRC (βλ. υπογραφή μου).
Ξεκινήστε έναν client από το εσωτερικό και έναν από το εξωτερικό υποδίκτυο. Σε κάθε έναν από αυτούς, μέσα από τα sch-scripts, κάντε δεξί κλικ → Εκτέλεση → Άνοιγμα κονσόλας → Διαχειριστή, τοπικά.
Εκεί δώστε τις παρακάτω εντολές, και επισυνάψτε το αποτέλεσμα (πάλι για κάθε έναν από αυτούς):
grep server /etc/hosts
nc -w 2 server 9571
cat /etc/ltsp_fat_chroot
getltscfg -a
Υπάρχουν σημαντικές διαφορές στην εντολή nc. Επισυνάπτω την έξοδο ενός τερματικού στο εσωτερικό δίκτυο και ενός στο εξωτερικό δίκτυο.
Πάντως όταν τρέχω την nc στο τερματικό του εξωτερικού δικτύου στο syslog καταγράφεται η γραμμή:
Jan 17 12:39:14 myria ldminfod[4886]: connect from 195.251.161.71 (195.251.161.71)
που φαντάζομαι σημαίνει ότι δεν αρνήθηκε ο server τη σύνδεση.
Για την επικοινωνία μέσω του irc δεν το έχω κάνει ποτέ, θα ρωτήσω έναν από τους τεχνικούς μας...
Το πρόβλημα φαίνεται να είναι ότι ο ldminfod δεν απαντάει στο εξωτερικό υποδίκτυο, αφού η εντολή nc δεν κατάφερε να πάρει απάντηση από τον ldminfod.
Από την άλλη, στο προηγούμενο μήνυμα επισυνάψατε log που λέει ότι συνδέεται κανονικά!
Jan 14 10:57:37 myria ldminfod[26720]: connect from 195.251.161.71 (195.251.161.71)
Έτσι δεν μπορώ να καταλάβω τι ακριβώς φταίει, πιθανώς κάποιο "περίεργο" firewall που έχετε στο τμήμα. Αν δεν βρείτε τι κόβει τη σύνδεση, δοκιμάστε να σχολιάσετε προσωρινά τη γραμμή "ldminfod: ALL" στο αρχείο /etc/hosts.deny. Αν και πάλι δεν δουλέψει, θα χρειαστεί IRC + remote support - δεν είναι κάτι δύσκολο, ένα κλικ στην υπογραφή μου από κάποιον browser.
Συγνώμη που επικοινωνώ από εδώ αλλά κάτι δεν έχω καταλάβει με το irc. Θα το δω.
Το πρόβλημα όμως το βρήκα!! και είναι το timeout, δηλαδή το -w 2
Αν δοκιμάσω με -w 10 λειτουργεί μια χαρά.
Άρα τώρα θα ήθελα να σας ρωτήσω τα εξής προφανή:
Πρώτον, από που μπορώ να αλλάξω αυτή την παράμετρο, και
δεύτερον για ποιο λόγο υπάρχει αυτή η παράμετρος ;
Επίσης μήπως θα πρέπει σε κάποια τεκμηρίωση του ltsp να προστεθεί ένα σχετικό σχόλιο;
Θα μπορούσε να πει κανείς ότι κατά κάποιο τρόπο αυτό είναι ένα είδος bug;
σας ευχαριστώ πολύ.
Ο σχετικός κώδικας βρίσκεται στο αρχείο ldm, εάν θέλετε αλλάξτε το και στη συνέχεια κάντε συμπίεση του εικονικού δίσκου:
$ grep 9571 /opt/ltsp/i386/usr/share/ltsp/screen.d/ldm
nc -q-1 -w 5 $SRV 9571 > /var/run/ldm/$SRV
Το -w 5 σημαίνει να περιμένει απάντηση το πολύ για 5 δευτερόλεπτα, γιατί αλλιώς αν π.χ. σ' αυτήν τη θύρα άκουγε κάποιος άλλος δαίμονας, το nc μπορεί να περίμενε για πάντα.
Ο ldminfod όμως θα έπρεπε να απαντάει σε 1/10 του δευτερολέπτου, οπότε τα 5 είναι υπερ-αρκετά:
$ time nc -w 5 10.160.31.10 9571
...
real 0m0.049s
...
Επομένως πιστεύω ότι κάπου αλλού βρίσκεται ο λόγος της τεράστιας καθυστέρησης, ενώ δεν έχει ακόμα εξηγηθεί το γιατί δουλεύει απροβλημάτιστα στο εσωτερικό και όχι στο εξωτερικό υποδίκτυο.
Θα ήταν παράλογο να υποθέσουμε ότι φταίει το switch του εξωτερικού δικτυου το οποίο έχει πάνω του πολλά άλλα μηχανήματα;
Δε νομίζω να φταίει το switch. Δοκιμάστε το: συνδέστε έναν υπολογιστή στην "εξωτερική" κάρτα δικτύου του server απευθείας με ένα cross καλώδιο χωρίς να παρεμβάλλεται switch, και τρέξτε την παραπάνω εντολή nc. Αν και πάλι ο ldminfod χρειάζεται πάνω από 1 δευτερόλεπτο για να απαντήσει, τότε φταίει κάποια ρύθμιση στο server.
Δυστυχώς σήμερα το πρωί ήρθαμε στη δουλειά και βρήκαμε τον δίσκο να μην λειτουργεί. Ένας HP Ultra SCSI320 HotPlug αξίας 800 ευρώ, πέθανε μέσα σε μια βδομάδα λειτουργίας, και η HP αρνείται να μας βοηθήσει χωρίς να έχουμε λέει συμβόλαιο... Αυτά μόνο στην Ελλάδα γίνονται... Κάποιος πρέπει να τους τραβήξει το αυτί αυτών των τύπων άγρια. Εννοείται ότι θα διαμαρτυρηθούμε στα κεντρικά στις ΗΠΑ για την απαράδεκτη συμπεριφορά του ελληνικού «υποκαταστήματος». Ξέρω ότι δεν έχει σχέση αυτό με το forum αλλά καλό είναι να ξέρουμε σε τι χώρα ζούμε...
Μέχρι να αποκαταστήσουμε το σύστημα σε νέο δίσκο, δεν μπορώ να δοκιμάσω βεβαίως τίποτα.
Θα τα ξαναπούμε, ευχαριστώ για όλα,
Αντώνης.