Το νήμα του Gentoo, version 1.0

[Gentoo]

Ίσως να μην το κατάλαβα καλά, αλλά τα κλειδιά δεν είναι της μορφής 2 εδώ και άπειρα χρόνια; Έτσι που το κατάλαβα εγώ, αυτό που δεν χρησιμοποιείται πλέον είναι ο SHA1 για επικοινωνία μεταξύ client - server. Οπότε θα έχεις πρόβλημα μόνο αν έχεις ένα παλιό client που στέλνει SHA1 σε ένα καινούριο server (ο οποίος έχει κάνει deprecate τον SHA1 και δεν τον υποστηρίζει) ή αν έχεις ένα νέο client (ο οποίος στέλνει SHA256 επειδή έχει κάνει deprecate τον SHA1) και στέλνεις σε ένα παλιό server ο οποίος δεν υποστήριζε τότε SHA256.

Τα κλειδιά δεν τα πειράζεις καθόλου. Μπορεί βέβαια να κατάλαβα άλλα αντί άλλων.

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

Πάντως, θυμάμαι σε κάποια φάση πριν 1-2 χρόνια, που δεν μπορούσα να συνδεθώ στον server επειδή είχα παλιά έκδοση ssh εκεί.

Κι έκτοτε, φροντίζω να αναβαθμίζω το openssh (και οτιδήποτε έχει να κάνει με πρωτόκολλα ασφαλείας) στον server. Το υπόλοιπο σύστημα το αναβαθμίζω συνήθως ανά 6μηνο.

[tsigarid]

Ίσως να μην το κατάλαβα καλά, αλλά τα κλειδιά δεν είναι της μορφής 2 εδώ και άπειρα χρόνια; Έτσι που το κατάλαβα εγώ, αυτό που δεν χρησιμοποιείται πλέον είναι ο SHA1 για επικοινωνία μεταξύ client - server. Οπότε θα έχεις πρόβλημα μόνο αν έχεις ένα παλιό client που στέλνει SHA1 σε ένα καινούριο server (ο οποίος έχει κάνει deprecate τον SHA1 και δεν τον υποστηρίζει) ή αν έχεις ένα νέο client (ο οποίος στέλνει SHA256 επειδή έχει κάνει deprecate τον SHA1) και στέλνεις σε ένα παλιό server ο οποίος δεν υποστήριζε τότε SHA256.

Τα κλειδιά δεν τα πειράζεις καθόλου. Μπορεί βέβαια να κατάλαβα άλλα αντί άλλων.

Και εγώ αυτό κατάλαβα, απλά καταργούν κάτι αρχαίο, αλλά επειδή τα public keys τα φτιάχνεις μία φορά και μετά τα ξεχνάς, όλο και κάποιος μπορεί να έχει ξεμείνει. Εγώ ας πούμε έχω σε ένα υπολογιστή ένα id_dsa.pub με ημερομηνία 2010

- - - Updated - - -

eselect news read all νομίζω είναι αυτό που ψάχνεις.

Ναι. Τώρα που το ξανατσέκαρα, αυτή είναι η εντολή.

[GoofyX]

gcc 11 (stable) στο portage...

[patch]

Για να μην αναβάθμισει σε php8 ο ενδεδειγμένος τρόπος είναι να κάνω mask η απλά php7 στο make.conf είναι οκ;

[GoofyX]

Mask το php:8.0 και είσαι οκ προς το παρόν.

[GoofyX]

Κουτσομπολιά:

2021-10-18-libxcrypt-migration-stable
Title migrating from glibc[crypt] to libxcrypt in stable
Author Andreas K. Hüttel <dilfridge@gentoo.org>
Author Sam James <sam@gentoo.org>
Posted 2021-10-18
Revision 1

The implementation of libcrypt.so within glibc has been deprecated
for a long time and will be removed in the near future.

For this reason, we are following other distributions (where
this has been tested for years already) and switching to the
external libxcrypt implementation, now also in stable installations.

This will be a regular update, and in nearly all cases you
will not have to take any action and not observe any problems.

We do recommend, however, that your system is *fully* up
to date first. This is a standard recommendation but in this
specific case, it is useful to have a simplified depgraph
to ensure that Portage is able to smoothly calculate
an upgrade path.

That is, please take the opportunity to fully upgrade your
systems now, before the migration occurs, to simplify matters.

This change will occur on 2021-11-01 for stable users.
~arch users by default should already have switched.

If for whatever reason you do *not* wish to switch now -
which is only delaying the inevitable - you
need to take the following steps:
* unmask and enable the crypt USE flag of sys-libs/glibc
* mask the system USE flag of sys-libs/libxcrypt
* mask >=virtual/libcrypt-2

If you wish to manually migrate now, there are a series
of steps described on the wiki (see below), but the outline is:
* unforce the crypt USE flag of sys-libs/glibc and disable it
* unmask the system and split-usr (if applicable) USE flag of sys-libs/libxcrypt
and enable it
* unmask ~virtual/libcrypt-2

Please note that if you last changed your password before ~2008,
it may be using md5crypt or similar other weak mechanisms in /etc/shadow;
a bug in PAM [0][1] may mean that you were unable to login. We recommend
using "passwd" to change/refresh your password so it is using modern
methods. A new version of PAM has been added to the tree to resolve this issue.

In some cases, Portage may schedule a rebuild of certain packages in an
incorrect order [2]. If building a package fails, please try upgrading
libcrypt and libxcrypt first:

# emerge -v1 virtual/libcrypt sys-libs/libxcrypt

And then continue the world upgrade with Portage's "--keep-going=y".

For more information or troubleshooting tips, please see:
* https://wiki.gentoo.org/wiki/Project...implementation
* https://bugs.gentoo.org/699422

[0] https://bugs.gentoo.org/802267
[1] https://bugs.gentoo.org/802807
[2] https://bugs.gentoo.org/802210

[mzaf]

Redcore Linux
https://9to5linux.com/redcore-linux-...ith-linux-5-14
Το ξέρετε; Καμιά γνώμη επ'αυτού;

[imitheos]

Redcore Linux
https://9to5linux.com/redcore-linux-...ith-linux-5-14
Το ξέρετε; Καμιά γνώμη επ'αυτού;

Προσωπικά δεν το έχω ακούσει. Διάβασα όμως ότι βασίζεται στο Kagaion ή κάπως έτσι, το οποίο βασιζόταν στο sabayon. Το sabayon το είχα ακούσει και το είχα δει λίγο αλλά δεν μου είχε αρέσει. Το κακό με αυτές τις διανομές είναι ότι έχουν εγγενή προβλήματα.

Αν μια διανομή προορίζεται σαν "gentoo installcd" δηλαδή να σου δώσει ένα headstart ώστε να έχεις γρήγορα ένα βασικό γραφικό σύστημα χωρίς να χρειάζεται να χτίσεις kernel, xorg, kde, κτλ και μετά είναι απλό gentoo, τότε οκ το δέχομαι γιατί γλυτώνεις τον αρχικό χρόνο που έχεις να χτίσεις 500 πακέτα μαζί.

Πολλές φορές όμως, φέρνουν δικά τους εργαλεία ώστε να μπορείς να συνεχίσεις να χρησιμοποιείς τα binary πακέτα χωρίς να χτίζεις. Αυτό όμως έχει εγγενή προβλήματα, όπως είπα πριν:
1) Αν δεν αλλάξεις την configuration και τρέχεις απλά τα binary πακέτα, τότε τι διαφορά έχει σε σχέση με το να βάλεις πχ debian; Τα πακέτα θα χτιστούν αναγκαστικά με κάποιο γενικό march ώστε να τρέχουν παντού οπότε το μόνο που κερδίζεις είναι ίσως λίγο λιγότερο bloated πακέτα λόγω ότι τα πακέτα θα χτιστούν μόνο με τις σημαίες USE που είναι ενεργοποιημένες από το Gentoo. Και πάλι όμως δεν έχει διαφορά από πχ debian.

2) Αν πειράξεις την configuration για κάποια πακέτα και χρησιμοποιείς binary για τα υπόλοιπα, συνήθως γ...ται ο δίας. Το είχα δοκιμάσει τότε στο sabayon και όλο έβγαιναν προβλήματα γιατί έμπλεκε το entropy με το emerge και τις εξαρτήσεις των binary πακέτων. Ίσως, βέβαια, να έκανα λάθος εγώ και να μην έκανα τη διαδικασία σωστά.

[mzaf]

Thanks, imitheos.

Αν μια διανομή προορίζεται σαν "gentoo installcd" δηλαδή να σου δώσει ένα headstart ώστε να έχεις γρήγορα ένα βασικό γραφικό σύστημα χωρίς να χρειάζεται να χτίσεις kernel, xorg, kde, κτλ και μετά είναι απλό gentoo, τότε οκ το δέχομαι γιατί γλυτώνεις τον αρχικό χρόνο που έχεις να χτίσεις 500 πακέτα μαζί.

Σε αυτή την περίπτωση θα είχε ενδιαφέρον.

[Gentoo]

Μετά από τυπικό update, ξαφνικά δεν μου εμφανίζει πουθενά το virtualbox (το εμφανίζει εγκατεστημένο στον portage και δούλευε μέχρι πρότινος).

Όταν πάω να το "τρέξω" απ'το πλήρες path, δεν κάνει τίποτα.

Πολύ περίεργο, δεν μου έχει ξανατύχει. Να σχετίζεται κάποιο lib; Καμιά python;

Δοκίμασα και να το ξαναχτίσω, μαζί με όλα τα συνοδευτικά του (modules, extensions, κλπ), αλλά δεν άλλαξε τίποτα.

[imitheos]

qlist virtualbox ή equery f virtualbox δεν εμφανίζουν αρχεία του πακέτου; Το εκτελέσιμο που τρέχεις από το full path υπάρχει και δεν απλά δεν τρέχει ή δεν υπάρχει καθόλου;

Δεν έγραψες αρκετές πληροφορίες.

[Gentoo]

qlist virtualbox ή equery f virtualbox δεν εμφανίζουν αρχεία του πακέτου; Το εκτελέσιμο που τρέχεις από το full path υπάρχει και δεν απλά δεν τρέχει ή δεν υπάρχει καθόλου;

Δεν έγραψες αρκετές πληροφορίες.

Υπάρχουν όλα τα αρχεία κανονικά. Απλώς δεν ξεκινάει τίποτα.

Δεν ξέρω τι άλλη πληροφορία να δώσω.

Τώρα που δοκίμασα να το τρέξω ως root, μου εμφανίζει αυτό:

VirtualBox
Qt WARNING: QStandardPaths: runtime directory '/run/user/1000' is not owned by UID 0, but a directory permissions 0700 owned by UID 1000 GID 1000
Qt WARNING: QStandardPaths: runtime directory '/run/user/1000' is not owned by UID 0, but a directory permissions 0700 owned by UID 1000 GID 1000

Είναι θέμα permissions μάλλον.

EDIT. Οκ, το έλυσα το πρόβλημα. Για κάποιο λόγο ο χρήστης μου δεν ήταν στους vboxusers. Μόλις τον πρόσθεσα, όλα οκ.

Παράξενο όμως γιατί δεν είχα κάνει κάποια αλλαγή σε αυτό, είχα την εντύπωση ότι και πριν τον είχα στους vboxusers.

Τι να πω, περίεργα πράγματα....

[imitheos]

VirtualBox
Qt WARNING: QStandardPaths: runtime directory '/run/user/1000' is not owned by UID 0, but a directory permissions 0700 owned by UID 1000 GID 1000
Qt WARNING: QStandardPaths: runtime directory '/run/user/1000' is not owned by UID 0, but a directory permissions 0700 owned by UID 1000 GID 1000

Είναι θέμα permissions μάλλον.

EDIT. Οκ, το έλυσα το πρόβλημα. Για κάποιο λόγο ο χρήστης μου δεν ήταν στους vboxusers. Μόλις τον πρόσθεσα, όλα οκ.

Παράξενο όμως γιατί δεν είχα κάνει κάποια αλλαγή σε αυτό, είχα την εντύπωση ότι και πριν τον είχα στους vboxusers.

Μήπως άλλαξε κάτι στην security και από εκεί που επιτρεπόταν να το τρέξεις χωρίς να είσαι στους vboxusers, τώρα πρέπει να είσαι; Έτσι στη τύχη το λέω, δεν το γνωρίζω.

Όσον αφορά το θέμα αδειών που είπες για το /run/user, εικάζω ότι έτρεξες su και όχι "su -" οπότε κληρονόμησες όλο το περιβάλλον του χρήστη για αυτό είχες σαν xdg_runtime το /run/user/1000. Ένας μικρός αριθμός προγραμμάτων (συνήθως που έχουν σχέση με την ασφάλεια πχ το gnupg) ελέγχουν αν ο κατάλογος που προσπαθείς να χρησιμοποιήσεις ανήκει σε εσένα και έχει τις σωστές άδειες και σε ενημερώνουν.

[Gentoo]

Μήπως άλλαξε κάτι στην security και από εκεί που επιτρεπόταν να το τρέξεις χωρίς να είσαι στους vboxusers, τώρα πρέπει να είσαι; Έτσι στη τύχη το λέω, δεν το γνωρίζω.

Δεν ξέρω. Δεν θυμάμαι αν είχα τον χρήστη μου στους vboxusers τόσο καιρό. Να βγήκε μόνος του, δεν ξέρω αν είναι εφικτό.

Όσον αφορά το θέμα αδειών που είπες για το /run/user, εικάζω ότι έτρεξες su και όχι "su -" οπότε κληρονόμησες όλο το περιβάλλον του χρήστη για αυτό είχες σαν xdg_runtime το /run/user/1000. Ένας μικρός αριθμός προγραμμάτων (συνήθως που έχουν σχέση με την ασφάλεια πχ το gnupg) ελέγχουν αν ο κατάλογος που προσπαθείς να χρησιμοποιήσεις ανήκει σε εσένα και έχει τις σωστές άδειες και σε ενημερώνουν.

Ναι, συνήθως με σκέτο su παίρνω root rights.

Μπορώ να το διορθώσω αυτό; Είναι εκνευριστικό καμία φορά

[imitheos]

Ναι, συνήθως με σκέτο su παίρνω root rights.

Μπορώ να το διορθώσω αυτό; Είναι εκνευριστικό καμία φορά

Μπορείς τρέχοντας "su -" και να μην τρέχεις σκέτο su

Όπως λες, στο 99% των περιπτώσεων θέλεις να έχεις το περιβάλλον που θα είχες αν έκανες login σαν root (ή όποιου χρήστη κάνεις su σε) οπότε θα έπρεπε αυτή να είναι η μανίσια λειτουργία και να πρέπει να βάλεις κάποια παράμετρο για να διατηρήσει το περιβάλλον του χρήστη. Δεν ξέρω γιατί είναι έτσι. Υποθέτω για ιστορικούς λόγους συμβατότητας.

[Η άχρηστη πληροφορία της ημέρας]
Η μόνη περίπτωση που μου έρχεται στο μυαλό είναι κάποιος χρήστης να έχει πρόβλημα, να μην παίζει κάτι (όπως πχ στη δική σου περίπτωση) αλλά το πρόβλημα να γίνεται trigger μόνο σε αυτόν και διαβάζοντας τα αρχεία του shell του, να μην βρίσκεις κάτι που να το δικαιολογεί. Έτσι μπορείς να κάνεις su και να διατηρήσεις ολόκληρο το περιβάλλον του ώστε να μπορέσεις να κάνεις trigger το πρόβλημα. Σε μηχάνημα με 400-500 χρήστες το οποίο διαχειριζόμουν για 7-8 χρόνια, μόλις μία φορά μου έτυχε αυτό. Και σε μια τέτοια περίπτωση ακόμη δεν συστήνεται να το κάνεις γιατί δεν είναι ασφαλές. Μπορεί ο χρήστης να έχει PATH=/home/user/τάδε:υπόλοιπο$PATH και να έχει μέσα ένα ls το οποίο να rootάρει το μηχάνημα, οπότε τρέχοντας ls, τρέχεις το binary του.
[/Η άχρηστη πληροφορία της ημέρας]