Re: [CentOS] non-functioning printer
On Fri, 14 May 2021 22:22:24 -0500 (CDT) Michael Hennebry wrote: > With the Deskjet D1420 disconnected, hp-probe > finds no USB printers (duh). > With the Deskjet D1420 connected, hp-probe > finds it. The exact test of the output from hp-probe -busb -g is The output from hp-testpage printername -g is The relevant parts of /var/log/messages, /var/log/cups/access_log and /var/log/cups/error-log and /var/log/cups/page_log are -- MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] non-functioning printer
With the Deskjet D1420 disconnected, hp-probe finds no USB printers (duh). With the Deskjet D1420 connected, hp-probe finds it. hp-testpage produces error: Unable to communicate with printer Deskjet-D1400-series. Please check the printer and try again. Note that hp-probe found it. hp-testpage also produces a popup saying ... There is a problem with a print cartridge (1017) It does not say which one or why this would cause communication failure. How do I figure this out? -- Michael henne...@web.cs.ndsu.nodak.edu "Sorry but your password must contain an uppercase letter, a number, a haiku, a gang sign, a heiroglyph, and the blood of a virgin." -- someeecards ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] getssl was working stopped
CA="https://acme-v02.api.letsencrypt.org; This is what my file has also Jerry ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] getssl was working stopped
On Fri, 14 May 2021 at 13:43, Jerry Geis wrote: > On Fri, May 14, 2021 at 11:52 AM Jerry Geis wrote: > > > Hi All - I am using getssl on CentOS 7. > > It have been working fine since Feb 17th and just stopped. > > > > My script: > > getssl -u -a -q > > getssl: for some reason could not reach > > > http://MY_NAME/.well-known/acme-challenge/lL_ublhWh3fnmbXhhh3BR3bdnjHoMFAgTimTvZUTLQM > > - please check it manually > > > > So I did check it manually from another machine - it works fine: > > curl > > > http://MY_NAME/.well-known/acme-challenge/lL_ublhWh3fnmbXhhh3BR3bdnjHoMFAgTimTvZUTLQM > > > > > > > lL_ublhWh3fnmbXhhh3BR3bdnjHoMFAgTimTvZUTLQM.tIS27xF0xtz7YHES31MATofXyCeyfqttq7B_YBYZetI > > > > So it works fine. > > > > I then thought perhaps a firewall issue. So I "systemctl stop firewalld", > > redid the getssl -u -a -q command above - and I get the same error. > > > > How do I see/tell what its not liking ? > > > > Thanks, > > > > Jerry > > > > I took off the -q as requested - doesnt say much more. > > > Redirecting to /bin/systemctl stop httpd.service > Check all certificates > MY_NAME: no certificate obtained from host > Registering account > Verify each domain > Verifying MY_NAME > copying challenge token to > > /var/www/html/.well-known/acme-challenge/lL_ublhWh3fnmbXhhh3BR3bdnjHoMFAgTimTvZUTLQM > getssl: for some reason could not reach > > http://MY_NAME/.well-known/acme-challenge/lL_ublhWh3fnmbXhhh3BR3bdnjHoMFAgTimTvZUTLQM > - please check it manually > Redirecting to /bin/systemctl start httpd.service > > > > I thought the -u does the automatic upgrade - > > getssl -v > getssl V2.36 > > I would check the getssl.cfg file and see if it is asking for version 1 acme certs. [ I do not use this software and am just going from https://github.com/srvrco/getssl where it has the certificate server it wants to use in the latest version to be CA="https://acme-v02.api.letsencrypt.org; -- Stephen J Smoogen. I've seen things you people wouldn't believe. Flame wars in sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law. All those moments will be lost in time... like posts on BBS... time to reboot. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] systemd and 'Stale file handle' errors?
Jonathan Billings wrote: > So, the chronyd systemd unit looks like this: > > # /usr/lib/systemd/system/chronyd.service > [Unit] > Description=NTP client/server > Documentation=man:chronyd(8) man:chrony.conf(5) > After=ntpdate.service sntp.service ntpd.service > Conflicts=ntpd.service systemd-timesyncd.service > ConditionCapability=CAP_SYS_TIME > > [Service] > Type=forking > PIDFile=/var/run/chrony/chronyd.pid > EnvironmentFile=-/etc/sysconfig/chronyd > ExecStart=/usr/sbin/chronyd $OPTIONS > ExecStartPost=/usr/libexec/chrony-helper update-daemon > PrivateTmp=yes > ProtectHome=yes > ProtectSystem=full > > [Install] > WantedBy=multi-user.target > > So, you'll notice there are "ProtectHome=yes" and "ProtectSystem=yes" > settings in the Service section. This sets up a private namespace for > the systemd unit so /home, /root and /run/user are made inaccessible > and empty (ProtectHome), and /usr, /boot and /etc are read-only > (ProtectSystem). It does this to reduce the ability of a malicious > NTP server attacking the system through bogus NTP traffic (which is a > real thing that can happen). Many systemd services limit their > processes this way. > > I suspect that is why you're seeing stale file handle errors, the > kernel can't set up the namespace for directories that are now stale > on the system. > > You can probably just do a lazy unmount (umount -l) to make them go > away until you reboot. You can also disable the namespaced > directories by doing a 'systemctl edit chronyd.service' and setting > the options to 'off', but you'll be reducing the security of your > system. Thanks - that all makes sense - unfortunately 'umount -l' didn't work :-( I've actually now rebooted the box - but if something like this happens again, maybe I could use a drop-in snippet in /run/systemd/system/ to turn the options off - which would then only last until the next reboot ? Thanks James Pearson ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] getssl was working stopped
On Fri, May 14, 2021 at 11:52 AM Jerry Geis wrote: > Hi All - I am using getssl on CentOS 7. > It have been working fine since Feb 17th and just stopped. > > My script: > getssl -u -a -q > getssl: for some reason could not reach > http://MY_NAME/.well-known/acme-challenge/lL_ublhWh3fnmbXhhh3BR3bdnjHoMFAgTimTvZUTLQM > - please check it manually > > So I did check it manually from another machine - it works fine: > curl > http://MY_NAME/.well-known/acme-challenge/lL_ublhWh3fnmbXhhh3BR3bdnjHoMFAgTimTvZUTLQM > > > lL_ublhWh3fnmbXhhh3BR3bdnjHoMFAgTimTvZUTLQM.tIS27xF0xtz7YHES31MATofXyCeyfqttq7B_YBYZetI > > So it works fine. > > I then thought perhaps a firewall issue. So I "systemctl stop firewalld", > redid the getssl -u -a -q command above - and I get the same error. > > How do I see/tell what its not liking ? > > Thanks, > > Jerry > I took off the -q as requested - doesnt say much more. Redirecting to /bin/systemctl stop httpd.service Check all certificates MY_NAME: no certificate obtained from host Registering account Verify each domain Verifying MY_NAME copying challenge token to /var/www/html/.well-known/acme-challenge/lL_ublhWh3fnmbXhhh3BR3bdnjHoMFAgTimTvZUTLQM getssl: for some reason could not reach http://MY_NAME/.well-known/acme-challenge/lL_ublhWh3fnmbXhhh3BR3bdnjHoMFAgTimTvZUTLQM - please check it manually Redirecting to /bin/systemctl start httpd.service I thought the -u does the automatic upgrade - getssl -v getssl V2.36 Thanks, Jerry ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] getssl was working stopped
On Fri, May 14, 2021 at 10:52 AM Jerry Geis wrote: > Hi All - I am using getssl on CentOS 7. > It have been working fine since Feb 17th and just stopped. > Are you using a recent version of getssl? Newer releases support ACMEv2 , and there is a planned brownout of ACMEv1 service in effect right now. You shouldbe migrating everything to ACMEv2 support only right now. https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430/16 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] getssl was working stopped
On Fri, 14 May 2021 at 11:52, Jerry Geis wrote: > Hi All - I am using getssl on CentOS 7. > which getssl are you using? I could assume https://github.com/srvrco/getssl but it could be all numbers of things. If it is that one, then it is written in bash so it should work via bash -x and removing the -q to get more data on what might be broken. It have been working fine since Feb 17th and just stopped. > > My script: > getssl -u -a -q > getssl: for some reason could not reach > > http://MY_NAME/.well-known/acme-challenge/lL_ublhWh3fnmbXhhh3BR3bdnjHoMFAgTimTvZUTLQM > - please check it manually > > So I did check it manually from another machine - it works fine: > curl > > http://MY_NAME/.well-known/acme-challenge/lL_ublhWh3fnmbXhhh3BR3bdnjHoMFAgTimTvZUTLQM > > > lL_ublhWh3fnmbXhhh3BR3bdnjHoMFAgTimTvZUTLQM.tIS27xF0xtz7YHES31MATofXyCeyfqttq7B_YBYZetI > > So it works fine. > > I then thought perhaps a firewall issue. So I "systemctl stop firewalld", > redid the getssl -u -a -q command above - and I get the same error. > > How do I see/tell what its not liking ? > > Thanks, > > Jerry > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos > -- Stephen J Smoogen. I've seen things you people wouldn't believe. Flame wars in sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law. All those moments will be lost in time... like posts on BBS... time to reboot. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] getssl was working stopped
Hi All - I am using getssl on CentOS 7. It have been working fine since Feb 17th and just stopped. My script: getssl -u -a -q getssl: for some reason could not reach http://MY_NAME/.well-known/acme-challenge/lL_ublhWh3fnmbXhhh3BR3bdnjHoMFAgTimTvZUTLQM - please check it manually So I did check it manually from another machine - it works fine: curl http://MY_NAME/.well-known/acme-challenge/lL_ublhWh3fnmbXhhh3BR3bdnjHoMFAgTimTvZUTLQM lL_ublhWh3fnmbXhhh3BR3bdnjHoMFAgTimTvZUTLQM.tIS27xF0xtz7YHES31MATofXyCeyfqttq7B_YBYZetI So it works fine. I then thought perhaps a firewall issue. So I "systemctl stop firewalld", redid the getssl -u -a -q command above - and I get the same error. How do I see/tell what its not liking ? Thanks, Jerry ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] systemd and 'Stale file handle' errors?
On Thu, May 13, 2021 at 02:15:15PM +, James Pearson wrote: > > I have a CentOS 7 system where I needed to restart chronyd - but the > systemctl restart failed with the error: > > systemd[1]: Starting NTP client/server... > systemd[43578]: Failed at step NAMESPACE spawning /usr/sbin/chronyd: Stale > file handle > systemd[1]: chronyd.service: control process exited, code=exited status=226 > > Turns out there are a couple of Stale NFS file handles from fuse > mounts (related to gvfsd) of sub directories under an NFS mounted > home directory server - but the home directory for the user in this > case, no longer exist (user has left) > > However, I have no idea why these 'Stale file handles' prevent a > service being started by systemd ? > > In this case, chronyd has nothing to do with NFS mounted user home > directories - so shouldn't really care ? > > I have tried everything I can think of to clear these stale mounts, > but with no luck > > Does anyone know why systemd complains about unconnected 'Stale file > handles' - and is there any way I can tell systemctl to start a > service regardless of these 'errors' ? > > Rebooting the host will be a last resort (the system is used by many > users) - but in the meantime, I've manually started the > /usr/sbin/chronyd binary directly, which runs fine So, the chronyd systemd unit looks like this: # /usr/lib/systemd/system/chronyd.service [Unit] Description=NTP client/server Documentation=man:chronyd(8) man:chrony.conf(5) After=ntpdate.service sntp.service ntpd.service Conflicts=ntpd.service systemd-timesyncd.service ConditionCapability=CAP_SYS_TIME [Service] Type=forking PIDFile=/var/run/chrony/chronyd.pid EnvironmentFile=-/etc/sysconfig/chronyd ExecStart=/usr/sbin/chronyd $OPTIONS ExecStartPost=/usr/libexec/chrony-helper update-daemon PrivateTmp=yes ProtectHome=yes ProtectSystem=full [Install] WantedBy=multi-user.target So, you'll notice there are "ProtectHome=yes" and "ProtectSystem=yes" settings in the Service section. This sets up a private namespace for the systemd unit so /home, /root and /run/user are made inaccessible and empty (ProtectHome), and /usr, /boot and /etc are read-only (ProtectSystem). It does this to reduce the ability of a malicious NTP server attacking the system through bogus NTP traffic (which is a real thing that can happen). Many systemd services limit their processes this way. I suspect that is why you're seeing stale file handle errors, the kernel can't set up the namespace for directories that are now stale on the system. You can probably just do a lazy unmount (umount -l) to make them go away until you reboot. You can also disable the namespaced directories by doing a 'systemctl edit chronyd.service' and setting the options to 'off', but you'll be reducing the security of your system. We've seen some weird stuff in the past related to this feature. For example, I couldn't unmount /home because a service with ProtectHome=read-only was running (cups), and 'fuser' and 'lsof' didn't show anything was using it. It's because the kernel namespace stuff operates as a mountpoint, so it's all kernel. Another fun issue I discovered is that we had some locally-developed services that used files in /tmp as a communication channel, and with PrivateTmp=yes set, they no longer could communicate. So it forced us to actually do the right thing and use more appropriate methods. It is kinda confusing but I do appreciate that I now have a lot of ways I can now lock down services beyond simple UNIX permissions. systemd is a rather neat init system. My complaints with it usually are with the parts that reach outside of being an init system (I'm looking at you, systemd-logind and systemd-resolved). -- Jonathan Billings ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS-docs] [centos/centos.org] branch master updated (97da336 -> 66005a6)
This is an automated email from the git hooks/post-receive script. rbowen pushed a change to branch master in repository centos/centos.org. from 97da336 link to cstream faq add 66005a6 Update status of dojo No new revisions were added by this update. Summary of changes: _includes/centos-news.html | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- To stop receiving notification emails like this one, please contact the administrator of this repository. ___ CentOS-docs mailing list CentOS-docs@centos.org https://lists.centos.org/mailman/listinfo/centos-docs
Re: [CentOS] systemd and 'Stale file handle' errors?
> I have a CentOS 7 system where I needed to restart chronyd - but the > systemctl restart failed with the error: > > systemd[1]: Starting NTP client/server... > systemd[43578]: Failed at step NAMESPACE spawning /usr/sbin/chronyd: > Stale file handle > systemd[1]: chronyd.service: control process exited, code=exited > status=226 > > Turns out there are a couple of Stale NFS file handles from fuse mounts > (related to gvfsd) of sub directories under an NFS mounted home directory > server - but the home directory for the user in this case, no longer exist > (user has left) > > However, I have no idea why these 'Stale file handles' prevent a service > being started by systemd ? > > In this case, chronyd has nothing to do with NFS mounted user home > directories - so shouldn't really care ? > > I have tried everything I can think of to clear these stale mounts, but > with no luck > > Does anyone know why systemd complains about unconnected 'Stale file > handles' - and is there any way I can tell systemctl to start a service > regardless of these 'errors' ? > > Rebooting the host will be a last resort (the system is used by many > users) - but in the meantime, I've manually started the /usr/sbin/chronyd > binary directly, which runs fine We're running large multi user systems with desktop sessions on Red Hat based systems for decades but it became increasingly painful after EL6 with the introduction of systemd in EL7. It may have improved the user experience on developers laptops but for our use case things are worse today... Regards, Simon ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
