Re: [CentOS] dont run cron.d- when cron.daily-scripts are running
On 2/13/19 3:29 AM, Leon Fauster via CentOS wrote: Am 12.02.2019 um 17:02 schrieb Gordon Messmer : */5 * * * * root pidof -x run-parts || your-command-here Thats a nice solution! Pragmatic and more accurate than the path I was on. Thanks! I should have noted that this will avoid starting your scripts if run-parts is running, but it won't prevent run-parts from starting while your script runs. If that's important, then you'll have to modify both your cron jobs and the system crontabs that start run-parts, and use a lock of one sort or another. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] DNSSEC Questions
On 2/13/19 3:51 AM, Alice Wonder wrote: I see you are using algorithm 7 - I would recommend switching to either algorithm 13 or at least to 8. Algorithm 7 uses a SHA1 hash. See https://tools.ietf.org/html/draft-ietf-dnsop-algorithm-update-04 That's a draft but soon will be an update to the standard. Algorithm 13 (ECDSAP256SHA256) results in much smaller keys and signatures and is equivalent to about RSA-3072 in strength, and it uses a SHA-256 hash. However note that changing algorithms will result in validation failure for few days unless done carefully. Okay thanks. What ever problems it might cause I think the Alaskan Malamute Assistance League can deal with for a day or two. Seeing as I already caused a problem last weekend I see no reason not to repeat this weekend! But at least I can give some warning :) As long as you don't change your KSK that information will not change. I kind of figured this out on my own this morning when I woke up around 7AM MST. I guess I wanted to turn a mole hill into a mountain. Thank you so much for your help Alice. -- Paul (ga...@nurdog.com) Cell: (303)257-5208 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Centos 7.6 & ether-wake
Everyone, I have not been able to get ether-wake to work waking up other centos 7.6 machines after the upgrade to Centos 7.6. Has anyone else had this problem, and if so any luck with a fix? Greg Ennis ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Support for Argon2 for password hashing
I found that EPEL has argon2-20161029-2, but the dovecot 2.2.36 in C7 does not use it. If I were to compile dovecot 2.3, it comes with argon2 built in. I don't want to get into the build business, I have other things demanding my time. It would be nice to have argon2, but my server is small, and sha512 is a lot better than md5. On 2/13/19 1:57 PM, Alice Wonder wrote: The version of libsodium in EPEL supports argon2 For php you can build the libsodium extension. Also php 7.2+ builds that extension if you specify it build time using --with-sodium=shared switch. For dovecot you have to build it against sodium which means building your own packages but it works. At least with modern upstream dovecot. On 2/13/19 5:18 AM, Robert Moskowitz wrote: Is there any information on adding support for Argon2? I have been working on my new mailserver and this came up in moving from the default MD5 hash to more 'modern' hashes like SHA256 and SHA512. Then I was pointed to the work behind Argon2, and I see that it is moving through the IRTF cfrg workgroup: draft-irtf-cfrg-argon2-04.txt It is a 'purpose built' hash for passwords, with recommendations that new implementations use it. Of course can't use it if crypt does not support it thanks ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] freeIPA from CR repo - conflicts
hi guys do you see the same by any chance? --> Processing Dependency: ipa-server-common = 4.6.4-10.el7.centos.2 for package: python2-ipaserver-4.6.4-10.el7.centos.2.noarch --> Processing Dependency: ipa-common = 4.6.4-10.el7.centos.2 for package: python2-ipaserver-4.6.4-10.el7.centos.2.noarch --> Finished Dependency Resolution Error: Package: python2-ipaserver-4.6.4-10.el7.centos.2.noarch (updates) Requires: ipa-server-common = 4.6.4-10.el7.centos.2 Installed: ipa-server-common-4.6.4-10.el7.centos.noarch (@cr) ipa-server-common = 4.6.4-10.el7.centos Error: Package: ipa-server-4.6.4-10.el7.centos.x86_64 (@cr) Requires: python2-ipaserver = 4.6.4-10.el7.centos Removing: python2-ipaserver-4.6.4-10.el7.centos.noarch (@cr) python2-ipaserver = 4.6.4-10.el7.centos Updated By: python2-ipaserver-4.6.4-10.el7.centos.2.noarch (updates) python2-ipaserver = 4.6.4-10.el7.centos.2 Error: Package: python2-ipaclient-4.6.4-10.el7.centos.2.noarch (updates) Requires: ipa-common = 4.6.4-10.el7.centos.2 Installed: ipa-common-4.6.4-10.el7.centos.noarch (@cr) ipa-common = 4.6.4-10.el7.centos Error: Package: python2-ipaclient-4.6.4-10.el7.centos.2.noarch (updates) Requires: ipa-client-common = 4.6.4-10.el7.centos.2 Installed: ipa-client-common-4.6.4-10.el7.centos.noarch (@cr) ipa-client-common = 4.6.4-10.el7.centos Error: Package: python2-ipalib-4.6.4-10.el7.centos.2.noarch (updates) Requires: ipa-common = 4.6.4-10.el7.centos.2 Installed: ipa-common-4.6.4-10.el7.centos.noarch (@cr) ipa-common = 4.6.4-10.el7.centos Error: Package: ipa-client-4.6.4-10.el7.centos.x86_64 (@cr) Requires: python2-ipaclient = 4.6.4-10.el7.centos Removing: python2-ipaclient-4.6.4-10.el7.centos.noarch (@cr) python2-ipaclient = 4.6.4-10.el7.centos Updated By: python2-ipaclient-4.6.4-10.el7.centos.2.noarch (updates) python2-ipaclient = 4.6.4-10.el7.centos.2 Error: Package: python2-ipaserver-4.6.4-10.el7.centos.2.noarch (updates) Requires: ipa-common = 4.6.4-10.el7.centos.2 Installed: ipa-common-4.6.4-10.el7.centos.noarch (@cr) ipa-common = 4.6.4-10.el7.centos You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Support for Argon2 for password hashing
The version of libsodium in EPEL supports argon2 For php you can build the libsodium extension. Also php 7.2+ builds that extension if you specify it build time using --with-sodium=shared switch. For dovecot you have to build it against sodium which means building your own packages but it works. At least with modern upstream dovecot. On 2/13/19 5:18 AM, Robert Moskowitz wrote: Is there any information on adding support for Argon2? I have been working on my new mailserver and this came up in moving from the default MD5 hash to more 'modern' hashes like SHA256 and SHA512. Then I was pointed to the work behind Argon2, and I see that it is moving through the IRTF cfrg workgroup: draft-irtf-cfrg-argon2-04.txt It is a 'purpose built' hash for passwords, with recommendations that new implementations use it. Of course can't use it if crypt does not support it thanks ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Support for Argon2 for password hashing
Am 13.02.2019 um 14:18 schrieb Robert Moskowitz: Is there any information on adding support for Argon2? Did you check the RHEL 8 beta? Alexander ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Support for Argon2 for password hashing
Is there any information on adding support for Argon2? I have been working on my new mailserver and this came up in moving from the default MD5 hash to more 'modern' hashes like SHA256 and SHA512. Then I was pointed to the work behind Argon2, and I see that it is moving through the IRTF cfrg workgroup: draft-irtf-cfrg-argon2-04.txt It is a 'purpose built' hash for passwords, with recommendations that new implementations use it. Of course can't use it if crypt does not support it thanks ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Cups Ink Levels
On Tue, 12 Feb 2019 at 19:44, Mark LaPierre wrote: > > Hey all, > > In this week's Open Source Highlights I read: > > "Check ink level: If you have an Epson, Canon, HP, or Sony printer, you > can see its ink level with a simple application. Look for the "ink" > package in your distribution repositories." > > I checked my package manager but I didn't find any "ink" package. Does > such a package exist for Centos? Is so, what it the package called? > I do not see anyone having packaged the command for CentOS. The source code is here http://ink.sourceforge.net/ and here http://libinklevel.sourceforge.net/ From the page: Libinklevel is a library for checking the ink level of your printer on a system which runs Linux or FreeBSD. It supports printers attached via USB. Currently printers of the following brands are supported: HP, Epson and Canon. Canon BJNP network printers are supported too. A detailed list of supported printers is available. This is not official software from the printer manufacturers. The goal of this project is to create a vendor independent API for retrieving the ink level of a printer connected to a Linux or FreeBSD box. You can download the current version here. So if your printer is connected by USB (or a Canon BJNP network) and one of the the 3 supported.. it can work for you. > -- > _ > °v° >/(_)\ > ^ ^ Mark LaPierre > Registered Linux user No #267004 > https://linuxcounter.net/ > > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos -- Stephen J Smoogen. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] dont run cron.d- when cron.daily-scripts are running
> Am 12.02.2019 um 17:02 schrieb Gordon Messmer : > > On 2/12/19 4:57 AM, Leon Fauster via CentOS wrote: >> I have some cron.d entries that execute scripts in minute intervals and I'm >> wondering how could an >> "official" way look like, to have a condition to not run cron.d entries when >> cron.daily scripts are >> running. Sure, I can hack something around file timestamps or so but that >> feels not so streamlined ... > > > run-parts doesn't look like it produces a lock, so I'd venture that the > simplest way would be: > > */5 * * * * root pidof -x run-parts || your-command-here > Thats a nice solution! Pragmatic and more accurate than the path I was on. Thanks! -- LF ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] DNSSEC Questions
On 2/12/19 11:49 PM, Paul R. Ganci wrote: On 2/12/19 10:55 PM, Alice Wonder wrote: DNSSEC keys do not expire. Signatures do expire. How long a signature is good for depends upon the software generating the signature, some lets you specify. ldns I believe defaults to 60 days but I am not sure. The keys are in DNSSKEY records that are signed by your Key Signing Key and must be resigning before the signature expires or they will no longer validate. Likewise, the other records in the zone must be resigned by your Zone Signing Key before their signatures expire. It's not the keys that are the issue, but the RRSIG record that contains a start and expiration time for the records. If you upload signed zone files to godaddy, make sure to resign once a week or so so that the RRSIG gets updated. man ldns-signzone Okay so I misunderstood the message I was getting when I checked my DNSSEC setup via http://dnsviz.net/. What you are telling me is that all I had to do was re-sign the zone files but that it was not necessary to generate new keys. This point is definitely one that I missed. I too run my own authoritative nameservers. I was following the Digital Ocean procedure to setup DNSSEC: https://www.digitalocean.com/community/tutorials/how-to-setup-dnssec-on-an-authoritative-bind-dns-server--2 That site suggested the use of dnssec-signzone after key creation ala a command like (the stuff that follows has been sanitized): > dnssec-signzone -3 `head -c 1000 /dev/random | sha1sum | cut -b 1-16` -N INCREMENT -o domain.tld -t domain.tld.zone After resigning with that command a file named dsset-domain.tld. is created which contains 2 digests. > cat dsset-domain.tld. domain.tld. IN DS 20716 7 1 04E3E6C87CD4190F74DD0371A14AD5CC42B71521 domain.tld. IN DS 20716 7 2 FA6D0EF0100855E5C85C6CD5A33590681DD9D7D9F6C773785C53E865 E02FF572 It is the keytag (20716) and the digests (hex fields) that are supposed to be uploaded to the registrar according to the section entitled "Configure DS records with the registrar" in the Digital Ocean reference I previously mentioned. In my original message it was the uploading of these keytags and digests to Godaddy that I was referring in my point 1 and which seems to be accomplished only manually via the Godaddy web interface. So doesn't ldns-signzone create the same kind of digest that requires it be uploaded to the registrar? Isn't that essential information in order to tell the .tld that the domain.tld DNSSEC is valid and to maintain the DNSSEC authentication chain trust up to the root servers? You can go to the http://dnsviz.net/ site and can use nurdog.com as an example of what i mean. The DS record does have to be uploaded to your registrar but it only changes when you change your Key Signing Key, as it is based on your Key Signing Key. I see you are using algorithm 7 - I would recommend switching to either algorithm 13 or at least to 8. Algorithm 7 uses a SHA1 hash. See https://tools.ietf.org/html/draft-ietf-dnsop-algorithm-update-04 That's a draft but soon will be an update to the standard. Algorithm 13 (ECDSAP256SHA256) results in much smaller keys and signatures and is equivalent to about RSA-3072 in strength, and it uses a SHA-256 hash. However note that changing algorithms will result in validation failure for few days unless done carefully. If I do not have to generate the keys every time the RRSIGs expire then the scripting or re-signing the zones is really trivial as I am in full control of my own DNS servers. It is even easier now if I don't have to generate new keys although that really isn't a difficult step. Yes that is what I do, daily via cron (or whenever I change a record) I resign it and upload. So maybe I asked the wrong question. Is there a way to re-sign the zone files without having to recreate the information found in that dsset-domain.tld. file and uploading it to the registrar? I suspect there is no way around that as I believe it is essential to maintaining the chain of trust. But if I can keep everything on my own nameservers that would be a big help ... maybe ldns-signzone is the answer? As long as you don't change your KSK that information will not change. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] /boot partition running out of space randomly. Please help!
In article , Sean Son wrote: > Hello all > > First off, I am running Oracle Linux 7.6 on a Hyper-V 2016 VM for a > customer. I know this is not an Oracle Linux mailling list, but because > Oracle Linux and CentOS are so similar, to an extent, I figured why not ask > on here because someone MIGHT know the answer.. Here is the issue. I have > a 600MB /boot partition allocated on a UEFI system. The /boot/efi partition > is on a separate EFI partition. Recently, I noticed that this system has > been crashing every few minutes and when I checked the disk space, I > noticed that the /boot partition has zero free space available. I removed > all of the old kernels and left the running kernel in place, in hopes that > will free up some space. It freed up about 50MB or so, but then the system > would crash again. After I would reboot the VM to bring the system back up, > I ran a df -h /boot, and the results were reporting ZERO disk space again > for the /boot partition.. It makes absolutely no sense how a partition > which is generally static UNLESS you move something into it, is running out > of space after space has been manually freed up in the partition! What > boggles me even more is that when I do an ls -lh /boot, the file systems do > not add up to 600M (well 594M) at all. See below: > > df -h > Filesystem Size Used Avail Use% Mounted on > devtmpfs 2.8G 0 2.8G 0% /dev > tmpfs 2.8G 0 2.8G 0% /dev/shm > tmpfs 2.8G 8.5M 2.8G 1% /run > tmpfs 2.8G 0 2.8G 0% /sys/fs/cgroup > /dev/mapper/VolGroup00-LogVolRoot 30G 19G 12G 63% / > /dev/sda2 594M 594M 0 100% /boot > /dev/sda1 238M 9.7M 229M 5% /boot/efi > /dev/mapper/VolGroup00-LogVolHome 3.3G 415M 2.9G 13% /home > tmpfs 565M 0 565M 0% /run/user/54321 > tmpfs 565M 0 565M 0% /run/user/1000 > > ]$ ls -lh /boot > total 92M > -rw-r--r-- 1 root root 179K Dec 12 22:52 > config-4.14.35-1844.0.7.el7uek.x86_64 > drwx-- 3 root root 16K Dec 31 1969 efi > drwx--. 2 root root 21 Feb 8 15:55 grub2 > -rw---. 1 root root 54M Aug 28 12:31 > initramfs-0-rescue-0287c4db206d4a9abe14f750b9091a01.img > -rw--- 1 root root 22M Dec 21 17:24 > initramfs-4.14.35-1844.0.7.el7uek.x86_64.img > -rw-r--r-- 1 root root 329K Dec 12 22:52 > symvers-4.14.35-1844.0.7.el7uek.x86_64.gz > -rw-r--r-- 1 root root 3.6M Dec 12 22:52 > System.map-4.14.35-1844.0.7.el7uek.x86_64 > -rwxr-xr-x. 1 root root 6.1M Aug 28 12:31 > vmlinuz-0-rescue-0287c4db206d4a9abe14f750b9091a01 > -rwxr-xr-x 1 root root 7.2M Dec 12 22:52 > vmlinuz-4.14.35-1844.0.7.el7uek.x86_64 > > I have no idea what is going on here and why the space keeps filling up and > the VM crashing! ANY and all help will be greatly appreciated! Thanks! Firstly, to see the space taken by everything on /boot without including the sub-mount /boot/efi, do this: # du -axk /boot Then if that doesn't account for all/most of the space, see if there are any processes holding a deleted file open: # fuser -m /boot Like you, I don't know what might be trying to fill up /boot when you are not installing a new kernel. Cheers Tony -- Tony Mountifield Work: t...@softins.co.uk - http://www.softins.co.uk Play: t...@mountifield.org - http://tony.mountifield.org ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
