Re: LUKS on shutdown.
When I try to umount them: /home and /other show as not mounted. / on the other hand, says busy. There are 4 entries in crypttab, the two listed by name above, presumably /, and I don't know what the other is. It is only listed by uuid, not sure how to correlate it to a mounted drive. When I got the output of /proc/mounts, lots of logical entries, and "/" Appeared to be the only real partition mounted. (proc, sysfs, none, and many more were there) On Sat, Dec 4, 2021 at 11:33 PM Gordon Messmer wrote: > On 12/4/21 19:15, murph nj wrote: > > > > > > Got another opportunity, redirected lsof /home and lsof /other to > > files, and there was no output. > > > Interesting... Is there an error if you try to unmount those yourself? > > > > I did get output from systemctl-list-jobs (edited lightly) > > > > JOB UNIT TYPE STATE > > 6039 systemd-cryptsetup@luks\x2dshome.service stop running > > 6068 systemd-cryptsetup@luks\x2de8.service stop running > > 6055 systemd-cryptsetup@luks\x2dsother.service stop running > > 6047 systemd-cryptsetup@luks\x2d23.service stop running > > > Home and other make sense given your earlier comment, but what are the > other two? Do the number of entries in /etc/crypttab match the number > of LUKS partitions? (What's in /proc/mounts during the failed shutdown?) When I try to umount them: /home and /other show as not mounted. / on the other hand, says busy. There are 4 entries in crypttab, the two listed by name above, presumably /, and I don't know what the other is. It is only listed by uuid, not sure how to correlate it to a mounted drive. When I got the output of /proc/mounts, (from the console when it was failing to shut down) lots of logical entries, and "/" Appeared to be the only real partition mounted. (proc, sysfs, none, and many more were there) ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[389-users] Re: Help - Missing nsAccount objectClass for WinSync users from AD
Thanks for your analysis. I've got it worked and i've found a problem in AD DN plugin. The filter was evaluating only objectClass=nsAccount. However your PAM config is for sure better than my, and i must confess i'm not a PAM guru. This will be a change to make a better understanding about the module by me. Regarding my second question which i summarize here: Once solved this issue, i think it would be better to sync AD user that belongs to specific AD Group in order to have a ore control over it instead of defining a specific OU. I've seen a page wich reports the existence of "Support Filters": https://directory.fedoraproject.org/docs/389ds/design/winsync-rfe.html#2-support-filters-1 And it says: new config parameters in windwows sync agreement: winSyncWindowsFilter: additional_filter_on_AD winSyncDirectoryFilter: additional_filter_on_DS Example: winSyncWindowsFilter: (|(cn=*user*)(cn=*group*)) winSyncDirectoryFilter: (|(uid=*user*)(cn=*group*)) Anyway it is not clear if my installed version support this feature 389-Directory/1.4.4.11 B2021.139.1122 If you could hekp also on this it will be really appreciate. Many Thanks ___ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[389-users] Re: Help - Missing nsAccount objectClass for WinSync users from AD
Thank you for your suggestions. I've got it working after realized that the problem were in AD DN plugin where addn_filter was set to evaluate only nsAccount as objectClass. However your PAM config looks better and i must confess, i am not a PAM guru. I will explore better this topic. Regarding my second question, reported here: i think it would be better to sync AD user that belongs to specific AD Group in order to have more control over it instead of defining a specific OU. I've seen a page which reports the existence of "Support Filters": https://directory.fedoraproject.org/docs/389ds/design/winsync-rfe.html#2-support-filters-1 And it says: new config parameters in windwows sync agreement: winSyncWindowsFilter: additional_filter_on_AD winSyncDirectoryFilter: additional_filter_on_DS Example: winSyncWindowsFilter: (|(cn=*user*)(cn=*group*)) winSyncDirectoryFilter: (|(uid=*user*)(cn=*group*)) Anyway it is not clear if my installed version support this feature 389-Directory/1.4.4.11 B2021.139.1122 Thanks for your support Appreciate ___ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: several issues with f34
> On 7 Dec 2021, at 09:30, Javier Perez wrote: > > > >> On Sat, Dec 4, 2021 at 10:13 AM Tom Horsley wrote: >> On Sat, 4 Dec 2021 15:16:05 +0800 >> Ed Greshko wrote: >> >> > So, you have a common keyboard, and monitor? I've not used a KVM switch >> > in a long time but they sometimes would cause >> > problems. >> >> A lot of KVM switches don't pass through EDID info correcly (especially >> for connections not currently active), there is a kernel option you >> can add to the kernel boot line to point at a binary blob of EDID >> info that will ovferride whatever incorrect nonsense it is getting from >> the KVM. Usually you just want to save the EDID from the real monitor >> when it is properly connected, then point the kernel at that so it >> will always know the right stuff. > > > Hi Sorry to barge in. > > How do I do that? Do you have a link I could go to and learn how to do it? > I have a KVM and whenever I switch from Fedora to the other PCs, I start > getting a bunch of lines on the journal complaining that the system could not > get the EDID info: > > "nvidia-modeset: WARNING: GPU:0: Unable to read EDID for display device VGA-0" For vga I recall that edid is sent over dedicated pins. It’s worth trying a different cable to see if the cable is the problem. Also try without the kvm in the way. Another thing to check is that the pins in the vga cable and socket have not been damaged. It used to be a problem that pins could get broken off or flattened into socket. Barry > > Thanks > > -- > -- > /\_/\ > |O O| pepeb...@gmail.com > Javier Perez > While the night runs > toward the day... > m m Pepebuho watches > from his high perch. > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[389-users] Re: Recent commits in stable 389ds branches - discussion
>>> 3) A new default plugin requirement, the plugin being written in Rust - >>> probably >>> its introduction is FIPS-related (Issue 3584 - Fix PBKDF2_SHA256 hashing in >>> FIPS mode). >> This was a very important fix to get into 1.4.4, usually big changes do not >> land >> in 1.4.4 anymore, but this one needed to get in. > > This change was about the C code, not Rust code if I recall correctly, since > that's the inbuilt PBKDF2_SHA256 module, not the pwdchan one with openldap > compat. The RUST pbkdf2 module has existed since early 1.4.4 and that's needed > for openldap migration which we at SUSE enable by default (I don't think RH do > yet). the changes in dse.ldif in that issue (3584) made libpwdchan-plugin required for the server (new entries in in cn=Password Storage Schemes,cn=plugins,cn=config). > > >>> See my comment >>> https://github.com/389ds/389-ds-base/issues/5008#issuecomment-983759224. >>> Rust >>> becomes a requirement for building the server, which is fine, but then it >>> should be enabled by default in "./configure". Without it the server does >>> not >>> compile the new plugin and complains about it when starting: >>> [01/Dec/2021:12:54:04.460194603 +0100] - ERR - symload_report_error - Could >>> not >>> open library "/Local/dirsrv/lib/dirsrv/plugins/libpwdchan-plugin.so" for >>> plugin >>> PBKDF2 >> Yes I do understand this frustration, and it is now fixed for non-rust >> builds. > > I think this error specifically came about if you did a rust build, then you > took rust away, it created some leftovers in dse.ldif I think (?). No, actually i have never installed rust on any of our production or build servers. dse.ldif now integrates by default rust-written plugins but --enable-rust is not a default option in ./configure, that was in fact the problem. Thank you, William! Sincerely, Andrey ___ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[389-users] Re: Recent commits in stable 389ds branches - discussion
Hi Mark,
thank you for your detailed reply. I do not have objections, it's just more of
a return of experience of the recent changes that i wanted to share, for me
some things were a bit unexpected. My comments are below.
On 12/3/21 6:29 AM, Ivanov Andrey (M.) wrote:
BQ_BEGIN
I'd like to discuss several recent (since a couple of months) commits in stable
branches of 389ds. I will be talking about 1.4.4 [
https://github.com/389ds/389-ds-base/tree/389-ds-base-1.4.4 |
https://github.com/389ds/389-ds-base/tree/389-ds-base-1.4.4 ] since it's the
one we are using in production, but i think it's the same for 1.4.3. These
commits are welcome and go in the right direction, however the changes they
produce are not something one expects when the server version changes in 4th
digit (ex. 1.4.4.17 -> 1.4.4.18). Here they are:
I guess we don't follow the same principles :-) For the most part these are all
minor RFE's except for Rust, but Rust has been in use in our product (1.4.x
series) for well over a year now, so I'm surprised to see issues arise about it
now. But adding these RFE's is not out of line IMHO, obviously you feel a
little different about that.
BQ_END
Yes, i would think these changes (especially the shift of certain files to
/dev/shm and rust dependency during server build) should have landed in 1.4.5
(corresponding to RHEL 8.n -> REHL 8.n+1).
If i take my experience as an example, the move of DB files to /dev/shm has
broken the startup of a newly created server (dscreate -f ...) since /dev/shm
size by default represents only 50% of server memory. In my case the size of
these files was more then 50% of memory, so i had to make adjustments (it was
either to increase the memory of the VM or change the parameter db_home_dir to
move the abovementioned files back to disk). As for the rust - i did not have
rust installed ever on my build server, i used my usual ./configure switches
that worked for 1.4.4.17, the server compiled OK but the error logs at startup
were filled up with "ERR" criticity messages. Anyway, the problem is resolved
and i think that as you say we don't have the same perception of change
importance vs. server version change.
BQ_BEGIN
1) Some database files [presumable memory-mapped files that are ok to be lost
at reboot] that were previously in /var/lib/dirsrv/slapd-instance/db/ are now
moved to /dev/shm/slapd-instance/. This modification seems to work fine (and
should increase performance), however there is an error message at server
startup when /dev/shm is empty (for example, after each OS reboot) when the
server needs to create the files:
BQ_BEGIN
[03/Dec/2021:12:12:14.887200364 +0100] - ERR - bdb_version_write - Could not
open file "/dev/shm/slapd-model/DBVERSION" for writing Netscape Portable
Runtime -5950 (File not found.)
After the next 389ds restart this ERR message does not appear, but it appears
after each OS reboot (since /dev/shm is cleaned up after each reboot).
BQ_END
We can look into modifying this behavior, especially since it's not a fatal
error. We can change the logging severity to NOTICE (from ERR) or something
like that.
BQ_END
Yes, i think that if it is not critical the logging severity for this
particular message should be lowered to NOTICE. Every message with ERR level
criticity makes me a bit nervous about server data sanity and integrity,
especially at startup
BQ_BEGIN
To be honest error log messages should not be expected to be static. As work is
done to the server logging messages are added/removed and/or changed all the
time, and that's not going to change.
BQ_END
I agree 100% with that, and as you say the criticity level of this finally
benign case (absence of " /dev/shm/slapd-xxx/DBVERSION" ) should be adjusted to
NOTICE in odrer not to scare the admin :))
BQ_BEGIN
Now I know when we added the "wtime" and "optime" to the access logging that
did cause some issues for Admins who parse our access logs. We could have done
better with communicating this change (live and learn). But at the same time
this new logging is tremendously useful, and has helped many customers
troubleshoot various performance issues. So while these changes can be
disruptive we felt the pro's outweighed the cons.
BQ_END
I found that change when it was introduced very interesting and useful tbh, it
simplifies debugging perfomance issues and lockups.
BQ_BEGIN
BQ_BEGIN
2) UNIX socket of the server was moved to /run/slapd-instance.socket, a new
keyword in .inf file for dscreate ("ldapi") has appeared.
Works fine, but it had an impact on our scripts that use ldapi socket path.
BQ_END
In this case using /var/run was outdated and was causing issues with
systemd/tmpfiles on RHEL, and moving it to /run was the correct thing to do.
What I don't understand is why adding the option to set the LDAPI path in the
INF file is a problem. Can you elaborate on that please?
BQ_END
It was not a problem, just
Re: several issues with f34
On Tue, 7 Dec 2021 04:29:40 -0500 Javier Perez wrote: > How do I do that? Do you have a link I could go to and learn how to do it? > I have a KVM and whenever I switch from Fedora to the other PCs, I start > getting a bunch of lines on the journal complaining that the system could > not get the EDID info: Search for EDID in the kernel command line parameters doc: https://www.kernel.org/doc/html/v4.14/admin-guide/kernel-parameters.html That tells you where to put the edid blob and how to point to it on the kernel command line. If you boot when the monitor is correctly connected, there should be a file like this: /sys/class/drm/card0-HDMI-A-1/edid That is the edid it read from the monitor which you can copy and point at on the command line. That card* directory is different depending on where the monitor is connected. There is also a read-edid tool that can dig up the same info. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: gnome extensions
> > On 07/12/2021 17:52, Patrick Dupre wrote: > > I found the way to reactive my extension. > > Sorry for the noise. > > Does this mean your "gnome environment" issue is resolved? Yes. I do not know haw it has been deactivated. > > -- > Did 황준호 die? > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: gnome extensions
On 07/12/2021 17:52, Patrick Dupre wrote: I found the way to reactive my extension. Sorry for the noise. Does this mean your "gnome environment" issue is resolved? -- Did 황준호 die? ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: gnome extensions
Sorry, I found the way to reactive my extension. Sorry for the noise. === Patrick DUPRÉ | | email: pdu...@gmx.com Laboratoire interdisciplinaire Carnot de Bourgogne 9 Avenue Alain Savary, BP 47870, 21078 DIJON Cedex FRANCE Tel: +33 (0)380395988| | Room# D114A === > Sent: Tuesday, December 07, 2021 at 10:48 AM > From: "Patrick Dupre" > To: "fedora" > Subject: gnome extensions > > Hello > > Using Tweaks, I do not have the tab Extension > How can I have it back? > > === > Patrick DUPRÉ | | email: pdu...@gmx.com > Laboratoire interdisciplinaire Carnot de Bourgogne > 9 Avenue Alain Savary, BP 47870, 21078 DIJON Cedex FRANCE > Tel: +33 (0)380395988| | Room# D114A > === > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
gnome extensions
Hello Using Tweaks, I do not have the tab Extension How can I have it back? === Patrick DUPRÉ | | email: pdu...@gmx.com Laboratoire interdisciplinaire Carnot de Bourgogne 9 Avenue Alain Savary, BP 47870, 21078 DIJON Cedex FRANCE Tel: +33 (0)380395988| | Room# D114A === ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: several issues with f34
On Sat, Dec 4, 2021 at 10:13 AM Tom Horsley wrote: > On Sat, 4 Dec 2021 15:16:05 +0800 > Ed Greshko wrote: > > > So, you have a common keyboard, and monitor? I've not used a KVM switch > in a long time but they sometimes would cause > > problems. > > A lot of KVM switches don't pass through EDID info correcly (especially > for connections not currently active), there is a kernel option you > can add to the kernel boot line to point at a binary blob of EDID > info that will ovferride whatever incorrect nonsense it is getting from > the KVM. Usually you just want to save the EDID from the real monitor > when it is properly connected, then point the kernel at that so it > will always know the right stuff. > Hi Sorry to barge in. How do I do that? Do you have a link I could go to and learn how to do it? I have a KVM and whenever I switch from Fedora to the other PCs, I start getting a bunch of lines on the journal complaining that the system could not get the EDID info: "nvidia-modeset: WARNING: GPU:0: Unable to read EDID for display device VGA-0" Thanks -- -- /\_/\ |O O| pepeb...@gmail.com Javier Perez While the night runs toward the day... m m Pepebuho watches from his high perch. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
gnome environment
Hello, I am lost bceause I lost my gnome environement. For example any of the frippery tools work. It just bother me. I do not remember how do I switch to different environments, like waylan org classic === Patrick DUPRÉ | | email: pdu...@gmx.com Laboratoire interdisciplinaire Carnot de Bourgogne 9 Avenue Alain Savary, BP 47870, 21078 DIJON Cedex FRANCE Tel: +33 (0)380395988| | Room# D114A === ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
