18.04 χωρίς sch-scripts

Ξεκίνησε από richard, 17 Ιουλ 2018, 06:50:15 ΜΜ

« προηγούμενο - επόμενο »

richard

Γεια σας

Ξανά κοίταξα την 18.04 με ltsp. Στο dnsmasq έβαλα port=53 και ένα workaround από το διαδίκτυο:

/etc/systemd/system/dnsmasq.service.d/resolved-fix.conf

[Unit]
After=systemd-resolved.service

[Service]
ExecStartPre=/bin/systemctl stop systemd-resolved.service
ExecStartPost=/bin/systemctl start systemd-resolved.service

Τώρα dnsmasq μπαίνει μπρος κανονικά και ένα client επίσης αλλά όταν το κλείνω από epoptes το client αρχήζει να κλείσει μέχρι :

starting Power-Off
Failed to open /dev/initctl: no such file
Failed to talk to init daemon
block nbd0: Connection timed out
Squashfs error: squashfs_read_data failed to read block 0x10c536b6

κ.λ.π.

Επειδή το ltsp με τη Debian Buster δουλεύει χωρίς πρόβλημα τι κάνει για να δουλεύει systemd-resolved μόνο με lo και όχι με το nic;

Richard

alkisg

Γεια σου Richard,

ξεκίνησα να δουλεύω το LTSP και τον Επόπτη και αργότερα θα προχωρήσω στα sch-scripts. Το LTSP είχε πολλά προβλήματα από τα οποία βρήκες 2-3. Έκανα ανακοίνωση για testing εδώ, αλλά είναι για τους ξένους μόνο, ενώ εμείς θα περιμένουμε τα sch-scripts.

Τα προβλήματα με το DNS τα είχα λύσει με αυτό το commit και με το shutdown με αυτό το commit. Δεν χρειάζεται να τα κάνεις apply μόνος σου, είναι ήδη στο Αποθετήριο της Τεχνικής Στήριξης.

Το Debian Buster έχει port=0 στο dnsmasq configuration από προεπιλογής, δηλαδή να μην χρησιμοποιεί DNS server, ενώ εμείς χρειαζόμαστε DNS server λόγω των cisco/mikrotik routers. Παρ' όλα αυτά έχει κι αυτό δεκάδες προβλήματα, όταν τελειώσω την νέα έκδοση του LTSP θα την κάνω upload κι εκεί.

Για εμάς, θα κάνω ανακοίνωση για testing όταν θα είναι ψιλοέτοιμα και τα sch-scripts.

richard

Να σαι καλά Άλκη. Θα δω τα commit σου. Στην Debian έβαλα # μπροστά τη γραμμή port=0 και δουλεύει.

Πριν να είδα την δημοσίευσή σου είχα ήδη ετοιμάζει:
============================================================
Γεια σας

Σήμερα σκάλιζα περισσότερα και κατάλαβα:

1 – επειδή και οι δύο υπηρεσίες, dnsmasq και resolvconf προσπαθούν να χρησιμοποιούν την ίδια θήρα 53 και η dnsmasq μπαίνει μπρος μετά, δηλαδή δεύτερη, βρήκε την 53 χρησιμοποιημένη και δεν έμπαινε μπρος. Ναι μεν στη προηγούμενη δημοσίευσή μου έγραψα πως αλλάζει την σειρά και μπαίνει μπρος η dnsmasq, μου διέφυγε το γεγονός ότι έχασα dns. Βεβαίωσα με τις εντολές:

sudo systemctl stop systemd-resolved
sudo systemctl stop dnsmasq
sudo systemctl start systemd-resolved

Δηλαδή ξανά έβαλα την resolvconf μπρος πρώτη και αμέσως ξανά είχα dns.

2 – επίσης, όταν μπαίνει η dnsmasq πρώτη η άλλη μπαίνει μεν αλλά δεν χρησιμοποιεί την 53:

systemd-resolved[1032]: Another process is already listening on TCP socket 127.0.0.53:53.
systemd-resolved[1032]: Turning off local DNS stub support.
systemd[1]: Starting resolvconf-pull-resolved.service...
dbus-daemon[702]: [system] Successfully activated service 'org.freedesktop.resolve1

3 – Όπως ανέφερα στη προηγούμενη δημοσίευσή μου, η Debian Buster δεν έχει τέτοια θέμα. Και οι δύο χρησιμοποιούν resolvconf 1.79 αλλά η Ubuntu την κανονίζει αλλώς. Με την εντολή

sudo systemd-resolve –status

βαίνουν πολλά, αλλά εδώ αναφέρει ότι κανονίζει:

Link 2 (enp1s0)

      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 127.0.0.1
                      195.170.0.1
                      195.170.2.2

Στην Debian η ίδια εντολή αναφέρει ότι δεν έχει τίποτα να πει.

Άρα αφήνει το network-manager να κανονίζει dns.

alkisg

Richard δεν κατάλαβα ποιο είναι το πρόβλημα. Με τις διορθώσεις που έκανα, δουλεύει και στο Ubuntu και στο Debian. Τώρα τι ψάχνουμε να βρούμε, γιατί εσένα σου δούλευε στο Debian ακόμα και χωρίς τις διορθώσεις;
Υπάρχουν πολλοί πιθανοί λόγοι, π.χ. μπορεί να έχεις εγκαταστήσει KVM ή libvirt κάτι σχετικό και να σου έχει ρυθμίσει το dnsmasq να κάνει bind-interfaces, το οποίο επιτρέπει στο dnsmasq να ακούει στην eth0:53 και το systemd-resolved να ακούει στην localhost:53. Από την άλλη, το bind-interfaces κάνει το dnsmasq ασταθές και τα sch-scripts επίτηδες το έβγαζαν από τις ρυθμίσεις του dnsmasq αν το έβλεπαν. Btw, ο network-manager στο Debian ποτέ δεν έτρεχε δικό του dnsmasq, όπως (κακώς) έκανε στο Ubuntu.

Αλλά εφόσον πλέον το DNS δουλεύει παντού, τι νόημα έχει να ψάχνουμε "γιατί δουλεύει και στην τάδε περίπτωση" όταν εκκρεμούν ένα σωρό άλλα πράγματα που δεν δουλεύουν; :)

richard

Εντάξει. Ευχαριστώ.

Richard