Το thread του Debian (v.4)

[imitheos]

Αν και αγαπαω το debian , και το χω δουλεψει πολυ καιρο , απο τις εμπειριες του τζιμη τεινω να καταλαβαινω οτι τον παιζουν εκει περα.Θελω καιρο να του πω να αλλαξει διανομη , αλλα μπορει να μην το αντεξει ψυχολογικα
Ας παει και στο gentoo αν ειναι να φυγει απο το debian ...θα το πω και ας με μουτζωσετε , ας παει και στο ubuntu στην τελικη

% eix \^beep$ 
* app-misc/beep
     Available versions:  1.3-r3 {suid}

Ο μόνος λόγος που θα σε μουτζώσουμε είναι αν θεωρείς το ubuntu πιο σοβαρό project από το debian

Καταλαβαίνω ότι το gentoo το αναφέρεις πιο πολύ σαν αστείο αλλά το gentoo έχει μεγάλη έλλειψη κόσμου με συνέπεια οι maintainers να τρέχουν και να μην φτάνουν. Εδώ ο firefox πολλές φορές μένει 3-4 εκδόσεις πίσω. Το MATE είναι ακόμη στο 1.18, κτλ. Στην προκείμενη περίπτωση, στο bug report που έδωσε ο jim αναφέρει έκδοση 1.4.3 ενώ όπως βλέπεις παραπάνω, στο gentoo υπάρχει μόνο η έκδοση 1.3 (δηλαδή το original repo και όχι το fork που είναι πιο μπροστά). Δηλαδή θα είναι στην ίδια κατάσταση (και χειρότερη) που είναι τώρα και θα αποκτήσει και το compile από πάνω.

Ειδικά ο jim_p που είναι τόσο τιτίζης θα του πέσουν τα μαλιά αν πάει στο gentoo Θα γράφει 4 bug reports κάθε ημέρα.

Αν σκέφτεται να μπει στο κόπο να αλλάξει, μόνο fedora / opensuse βλέπω σαν λύση για αυτόν (άντε και κανένα mint ίσως) με πιο πολύ fedora.

[jim_p]

Systemd 241 απο σημερα. Τελικα ειμαστε ή δεν ειμαστε σε freeze? Μαλλον οχι...
https://tracker.debian.org/news/1031...into-unstable/

[jim_p]

Google Chrome/Chromium Begins Landing POWER PPC64LE Patches
https://phoronix.com/scan.php?page=n...-POWER-Landing

Το βαζω εδω αν και ειναι ασχετο με το debian, επειδη απο τωρα μυριζομαι καθυστερησεις μηνων στα πακετα του testing που δεν θα χτιζονται για την καθε ασημαντη αρχιτεκτονικη.

[jim_p]

Εχετε και εσεις εναν φακελο /var/backups που εχει μεσα ολα τα παλια logs απο το φακελο /var/logs? Αν νια, τι τον δημιουργει?

[imitheos]

Εχετε και εσεις εναν φακελο /var/backups που εχει μεσα ολα τα παλια logs απο το φακελο /var/logs? Αν νια, τι τον δημιουργει?

Έτσι που το έγραψες, στην αρχή νόμισα κάποιο custom debian config του logrotate που αντί να κάνει rotate μέσα στο /var/log τα πάει σε άλλο κατάλογο αλλά κοιτάζοντας μέσα στο /var/backups μου έχω μόνο αρχεία σχετικά με το apt οπότε σκέφτηκα να κοιτάξω την manpage του low level component που είναι το dpkg και όντως αναφέρει τον κατάλογο.

/var/lib/dpkg/status
Statuses of available packages. This file contains information about whether a package is marked for removing or not, whether it is installed or not, etc. See section INFORMATION ABOUT PACKAGES for more info.

The status file is backed up daily in /var/backups. It can be useful if it's lost or corrupted due to filesystems troubles.

Δεν το γνωρίζω στα σίγουρα, αλλά το παραπάνω το ερμηνεύω ότι εκεί σώζονται αρχεία που έχουν να κάνουν με την κατάσταση των πακέτων. Το ίδιο backup γίνεται και στις rpm distros για τον κατάλογο /var/lib/rpm ώστε αν πάεθ κάτ η βάση να μην φαίνεται ότι στο σύστημα δεν υπάρχουν εγκατεστημένα πακέτα και έχεις πρόβλημα με τον package manager.

[jim_p]

Οποτε τι να τα κανω? Να τα πεταξω?

[mzaf]

Έχω αυτά,στο var/backups

[jim_p]

Μου κλεισανε το bug report για το beep, προσθετοντας μονο τον udev rule στο πακετο για να μην τον γραψω με το χερι και παλι σε σημειο που να μην διαβαζεται (τον εχει στο /lib/udev/rules.d/ και πρεπει να τον βαλω με το χερι στο /etc/udev/rules.d/). Ουτε το γκρουπ κανει, ουτε αλλαζει τα permissions που ειναι απαραιτητα και τα 2. Φταιω εγω μετα που τους κραζω?

[Jojos170304]

Ειδικά ο jim_p που είναι τόσο τιτίζης θα του πέσουν τα μαλιά αν πάει στο gentoo Θα γράφει 4 bug reports κάθε ημέρα.

Τιτίζης αχαχαχαχαχααααααααααααααα

[jim_p]

Πριν αρχισω τα μπινελικια για το beep, ας μου πει καποιος ποιος ειναι ο ρολος του /lib/udev/rules.d/.
Οτι εχει μεσα εκει φορτωνεται σαν rule? Ή πρεπει να παει στο /etc/udev/rules.d για να φορτωθει? Αντεγραψα το rule που παρεχει πλεον το πακετο απο τον ενα φακελο στον αλλο, τσεκαρα οτι ο χρηστης μου ειναι στο beep αλλα παλι beep δεν εχω. Και το getfacl λεει τα προηγουμενα, αυτα που ελεγε στην αρχη πριν χρειαστει να αλλαξω κατι.

Ανετα το χειροτερο maintnance patch που εχω δει τα τελευταια 10 χρονια στο debian!

#kavalimenoi

[imitheos]

Πριν αρχισω τα μπινελικια για το beep, ας μου πει καποιος ποιος ειναι ο ρολος του /lib/udev/rules.d/.
Οτι εχει μεσα εκει φορτωνεται σαν rule? Ή πρεπει να παει στο /etc/udev/rules.d για να φορτωθει? Αντεγραψα το rule που παρεχει πλεον το πακετο απο τον ενα φακελο στον αλλο, τσεκαρα οτι ο χρηστης μου ειναι στο beep αλλα παλι beep δεν εχω. Και το getfacl λεει τα προηγουμενα, αυτα που ελεγε στην αρχη πριν χρειαστει να αλλαξω κατι.

Ανετα το χειροτερο maintnance patch που εχω δει τα τελευταια 10 χρονια στο debian!

#kavalimenoi

Ο /lib/τάδε (είτε μιλάμε για udev είτε για το systemd ή για άλλα προγράμματα) είναι ο system κατάλογος στον οποίον εγκαθιστούνται κανόνες από την διανομή κατά την εγκατάσταση πακέτων. Ο /etc/τάδε είναι ο κατάλογος στον οποίον εισάγεις εσύ σαν διαχειριστής κανόνες και υπερνικούν ή συμπληρώνουν τους κανόνες συστήματος.

Με λίγα λόγια δηλαδή, ο κανόνας θα φορτώνεται κανονικά από τον /lib/udev. Αν ο κανόνας είναι σωστός, τότε θα πρέπει να παίζει σωστά. Αν εσύ θέλεις να αλλάξεις κάτι από τον κανόνα αυτό, τότε μόνο θα εισάγεις κάποιο κανόνα στο /etc.

[pmav99]

όπως τα λέει o imitheos. Για περισσότερες πληροφορίες: man 5 systemd-system.conf

CONFIGURATION DIRECTORIES AND PRECEDENCE
The default configuration is defined during compilation, so a configuration file is only needed when it is necessary to deviate from those defaults. By default, the configuration file in /etc/systemd/ contains commented out entries showing the defaults as a guide to the administrator. This file can be edited to create local overrides.

When packages need to customize the configuration, they can install configuration snippets in /usr/lib/systemd/*.conf.d/. Files in /etc/ are reserved for the local administrator, who may use this logic to override the configuration files installed by vendor packages. The main configuration file is read before any of the configuration directories, and has the lowest precedence; entries in a file in any configuration directory override entries in the single configuration file. Files in the *.conf.d/ configuration subdirectories are sorted by their filename in lexicographic order, regardless of which of the subdirectories they reside in. When multiple files specify the same option, for options which accept just a single value, the entry in the file with the lexicographically latest name takes precedence. For options which accept a list of values, entries are collected as they occur in files sorted lexicographically. It is recommended to prefix all filenames in those subdirectories with a two-digit number and a dash, to simplify the ordering of the files.

To disable a configuration file supplied by the vendor, the recommended way is to place a symlink to /dev/null in the configuration directory in /etc/, with the same filename as the vendor configuration file.

[imitheos]

Δεν είναι τόσο απλό το πράγμα όσο λέει η manpage αλλά παίζουν πολλοί παράγοντες. Με λίγο ψάξιμο όμως που έκανα θα έπρεπε να παίζει σωστά στον jim_p.

Όπως βλέπουμε εδώ, ο κανόνας που χρησιμοποιεί το upstream project είναι ο εξής:

ACTION=="add", SUBSYSTEM=="input", ATTRS{name}=="PC Speaker", ENV{DEVNAME}!="", RUN+="/usr/bin/setfacl -m g:beep:w '$env{DEVNAME}'"

δηλαδή τρέχει χειροκίνητα το setfacl και δίνει άδειες στην ομάδα beep.

Πηγαίνοντας στην σελίδα του debian και κατεβάζοντας το πακέτο του beep (αν κατέβασα το σωστό πακέτο είναι το 1.4.3-2 του unstable), έχει τον κανόνα /lib/udev/rules.d/70-pcspkr-beep.rules ο οποίος περιέχει το παρακάτω:

ACTION=="add", SUBSYSTEM=="input", ATTRS{name}=="PC Speaker", ENV{DEVNAME}!="", TAG+="uaccess"

Δηλαδή απλά ενεργοποιεί την ταμπέλα uaccess. Αυτή είναι πιο δόκιμη μέθοδος γιατί δεν χρειάζεται να δημιουργείς περιττές ομάδες αλλά χρησιμοποιεί μια υποδομή του systemd. Εδώ όμως είναι αυτό που είπα ότι δεν είναι τόσο απλό το πράγμα όσο λέει η manpage. Οι κανόνες που έχουν μέσα TAG, RUN, κτλ έχουν πρόσθετες προϋποθέσεις. Μία είναι ότι η ταμπέλα πρέπει να είναι ενεργοποιημένη πριν τρέξει το αρχείο κανόνων που τις ελέγχει.

Το πρώτο πράγμα λοιπόν που πήγε το μυαλό μου όταν είδα το TAG ήταν ότι το όνομα του κανόνα ήταν λάθος οπότε έψαξα να δω πώς ονομάζεται το αρχείο που ελέγχει τις ταμπέλες. Το όνομά του είναι 73-seat-late.rules οπότε όλα τα αρχεία που έχουν μέσα την ταμπέλα uaccess πρέπει να έχουν όνομα μικρότερο από 73. Όπως βλέπουμε όμως, ο κανόνας μετονομάστηκε από 90 που ήταν στο upstream project σε 70 άρα ο maintainer έκανε σωστή δουλειά και θα έπρεπε να παίζει σωστά στον jim_p.

[jim_p]

Μηπως το προβλημα μου ειναι εδω

# getfacl /dev/input/by-path/platform-pcspkr-event-spkr
    getfacl: Removing leading '/' from absolute path names
    # file: dev/input/by-path/platform-pcspkr-event-spkr
    # owner: root
    # group: input
    user::rw-
    group::rw-
    group:beep:-w-
    group:wheel:-w-
    mask::rw-
    other::---

που αντι για το παραπανω εγω παιρνω

# getfacl /dev/input/by-path/platform-pcspkr-event-spkr
getfacl: Removing leading '/' from absolute path names
# file: dev/input/by-path/platform-pcspkr-event-spkr
# owner: root
# group: input
user::rw-
group::rw-
other::---

[imitheos]

Μηπως το προβλημα μου ειναι εδω
που αντι για το παραπανω εγω παιρνω

# getfacl /dev/input/by-path/platform-pcspkr-event-spkr
getfacl: Removing leading '/' from absolute path names
# file: dev/input/by-path/platform-pcspkr-event-spkr
# owner: root
# group: input
user::rw-
group::rw-
other::---

Γιατί όμως να μην έχεις άδειες;

Εγκατέστησα χειροκίνητα με "dpkg -i" το πακέτο 1.4.3-2 για να μην ψάχνω πώς να το βάλω μέσω apt και βλέπω ότι δουλεύει σωστά σε εμένα.

$ getfacl /dev/input/by-path/platform-pcspkr-event-spkr
user::rw-
user:ll:rw-
group::rw-
mask::rw-
other::---

Αν κάνω login σαν root, παίρνω το 2ο αποτέλεσμα που έδωσες επειδή σαν root δεν χρειάζεται να τρέξει ο κανόνας. Όπως όμως βλέπεις παραπάνω, αν μπω σαν χρήστης ll, τότε υπάρχει ACL που μου δίνει άδειες.