Re: [CentOS] bare-metal backup before update--options?
> On Mon, Feb 11, 2019 at 04:16:38PM +0100, Simon Matter via CentOS wrote: >> > Hi all! >> > >> > I'm a "nervous nellie", I have not yet updated my 7.5 desktop to 7.6 >> > because (1) it has an Nvidia card, and (2) I've heard of problems >> > upgrading on top of software RAID (using RAID1 with 2 drives). >> > >> > I need to upgrade it to stay secure, and I want to do a bare-metal >> backup >> > first (so I can put it all back as it now is, in case it explodes in >> my >> > face), so I'm trying to figure out the safest way to do that. Here are >> > the choices as I see them, I'd appreciate comments/thoughts: >> > >> > 1. boot from live DVD and manually reassemble the RAID array (how >> > would I do that?) >> > 2. degrade the array (with appropriate commands) so that it is running >> > on just one drive, then boot a live DVD and use dd to back up that >> drive. >> > 3. Other choices you can suggest? >> > >> > then after successfully getting a bare-metal backup, reboot it with >> the >> > full RAID array and run the update. >> > >> > Thanks in advance! >> >> To me the easiest method seems to: >> >> - boot into rescue mode, not mounting any disks >> - directly dd all complete disks to files on a USB disk or to a remote >> host >> - reboot and update as usual >> >> If anything fails you can again boot into rescue mode (maybe with the >> help >> of USB/DVD/CD) and: >> >> - recover all disks using dd from the backups made before >> - reboot and be back on 7.5 >> >> Any reason why this shouldn't work? > > Thanks for the reply! > > by rescue mode, do you mean (1) the "rescue" kernel in the boot menu? > Or (2) an option on one of the installer DVDs? > > Wouldn't (1) boot from the existing drives and mount them? I'm not sure about the rescue mode in CentOS 7 but booting from external media will work for sure. Simon ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] dont run cron.d- when cron.daily-scripts are running
EL6 context: cronie-1.4.4-16.el6_8.2.x86_64 cronie-anacron-1.4.4-16.el6_8.2.x86_64 crontabs-1.10-33.el6.noarch 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 ... I'd really appreciate any ideas ... -- LF ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] dont run cron.d- when cron.daily-scripts are running
Well, this is anything but elegant, but if your daily occurs at an exact hour and minute you could write two series of per minute cron jobs (a "before' and an "after") avoiding that minute. Leroy Tennison Network Information/Cyber Security Specialist E: le...@datavoiceint.com 2220 Bush Dr McKinney, Texas 75070 www.datavoiceint.com This message has been sent on behalf of a company that is part of the Harris Operating Group of Constellation Software Inc. These companies are listed here . If you prefer not to be contacted by Harris Operating Group please notify us . This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged or confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message. From: CentOS on behalf of Leon Fauster via CentOS Sent: Tuesday, February 12, 2019 6:57 AM To: CentOS mailing list Subject: [EXTERNAL] [CentOS] dont run cron.d- when cron.daily-scripts are running EL6 context: cronie-1.4.4-16.el6_8.2.x86_64 cronie-anacron-1.4.4-16.el6_8.2.x86_64 crontabs-1.10-33.el6.noarch 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 ... I'd really appreciate any ideas ... -- LF ___ 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] dont run cron.d- when cron.daily-scripts are running
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 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] weird RPM dependency error; '/bin/sh' needed, but is provided
First off, I have to admit that I'm uncertain if this is the
appropriate forum; I'd be happy for suggestions about where else
to look.
I'm doing this work on a stock install of CentOS-7-x86_64-Minimal-1810.iso,
with no updates.
I'm trying to create an RPM database from a custom set of RPMs.
One RPM ('openldap-ltb' from the LDAP Tool Box project (ltb-project.org)
has a dependency on '/bin/sh'. The bash RPM is demonstratedly
present, yet the the 'rpm' utility thinks this dependency is not
met.
I'm open to any advice as to how to progress.
It pretty easy to demonstrate what's going wrong, rather than trying
to describe it.
Straightforward to reproduce:
Here, I collect the misc bits from the net:
$ wget --quiet
http://mirrors.mit.edu/centos/7/isos/x86_64/CentOS-7-x86_64-Minimal-1810.iso
$ wget --quiet
http://mirrors.mit.edu/centos/7/os/x86_64/Packages/libtool-ltdl-2.4.2-22.el7_3.x86_64.rpm
$ wget --quiet
https://ltb-project.org/archives/berkeleydb-ltb-4.6.21.NC-4.el7.patch4.x86_64.rpm
$ wget --quiet
https://ltb-project.org/archives/openldap-ltb-2.4.47-1.el7.x86_64.rpm
Now, I try to make an RPM database of these packages. The last step fails
with an unmet dependency:
$ sudo mount ~/CentOS-7-x86_64-Minimal-1810.iso -r -t iso9660 -o loop /mnt
$ mkdir -p ~/local_rpm_db
$ rpm --initdb --dbpath ~/local_rpm_db
$ rpm --justdb --ignoresize --dbpath ~/local_rpm_db -Uvh /mnt/Packages/*.rpm
*.rpm
warning: /mnt/cdrom/Packages/acl-2.2.51-14.el7.x86_64.rpm: Header V3
RSA/SHA256 Signature, key ID f4a80eb5: NOKEY
warning: berkeleydb-ltb-4.6.21.NC-4.el7.patch4.x86_64.rpm: Header V4 DSA/SHA1
Signature, key ID 6d45bfc5: NOKEY
error: Failed dependencies:
/bin/sh is needed by openldap-ltb-2.4.47-1.el7.x86_64
Which is weird, as the 'bash' RPM is clearly part of the set, and 'provides'
the needed feature:
$ rpm -q -provides -p /mnt/Packages/bash-4.2.46-31.el7.x86_64.rpm | egrep
'sh$'
/bin/bash
/bin/sh
Further, it's not among the list of files in the payload of the RPM:
$ rpm -q -l -p /mnt/Packages/bash-4.2.46-31.el7.x86_64.rpm | egrep 'sh$'
/usr/bin/bash
/usr/bin/sh
These tactics did work with the related bits for CentOS 6.
Here are some details of my environment; I'm happy to provide more, if
anyone has any questions:
$ cat /etc/redhat-release
CentOS Linux release 7.6.1810 (Core)
$ rpm -qf /usr/bin/rpm
rpm-4.11.3-35.el7.x86_64
--
Brian Reichert
BSD admin/developer at large
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [SOLVED] persistent generic device for tape changer
Good evening,
my final solution:
SUBSYSTEM=="scsi_generic", SUBSYSTEMS=="scsi", ATTRS{type}=="8",
ATTRS{model}=="MAGNUM 224 ", IMPORT{program}="scsi_id
--sg-version=3 --export --whitelisted -d $devnode", \
SYMLINK+="changer0"
SUBSYSTEM=="scsi_generic", SUBSYSTEMS=="scsi", ATTRS{type}=="8",
ATTRS{model}=="FlexStor II ", ATTRS{rev}=="5.11",
IMPORT{program}="scsi_id --sg-version=3 --export --whitelisted -d
$devnode", \
SYMLINK+="changer1"
SUBSYSTEM=="scsi_generic", SUBSYSTEMS=="scsi", ATTRS{type}=="8",
ATTRS{model}=="FlexStor II ", ATTRS{rev}=="5.50",
IMPORT{program}="scsi_id --sg-version=3 --export --whitelisted -d
$devnode", \
SYMLINK+="changer2"
Very helpful:
/dev/sch0, /dev/sch1, /dev/sch2 are persistent devices - but not generic
devices.
udevadm info -a /dev/sch0
shows all possible attributes in the udev rules key format.
best regards
Helmut
Viele Grüße
Helmut Drodofsky
Internet XS Service GmbH
Heßbrühlstraße 15
70565 Stuttgart
Geschäftsführung
Helmut Drodofsky
HRB 21091 Stuttgart
USt.ID: DE190582774
Fon: 0711 781941 0
Fax: 0711 781941 79
Mail: i...@internet-xs.de
www.internet-xs.de
Am 08.02.2019 um 12:21 schrieb Leon Fauster via CentOS:
>> Am 08.02.2019 um 00:13 schrieb Ron Loftin :
>>
>> On Thu, 2019-02-07 at 22:29 +0100, Helmut Drodofsky wrote:
>>> Hello Ron,
>>>
>>> sounds good. I have 2 tape changer. I persume, udev creates the same
>>> link for both.
>>>
>>> Can I modify
>>> SYMLINK+="changer-$env{ID_SERIAL}"
>>>
>>> The serial should be unique.
>>>
>>> Viele Grüße
>>> Helmut Drodofsky
>>>
>>>
>> I've taken you as far as I can go. Now you will have to experiment a
>> bit for your use case. I should point out that at least in my system,
>> the link with the serial number in it shows up even with the line
>> commented in the rules file.
>>
>> As always, YMMV.
> Maybe
>
> ATTRS{serial}=="likethis16c07338d2a294c" , SYMLINK+="mybackup/changer1"
> ...
>
> and for the second one
>
> ... ATTRS{serial}=="likethis9ae76c073f5ccb8" , SYMLINK+="mybackup/changer2"
> ...
>
> ?
>
> --
> LF
> ___
> 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] weird RPM dependency error; '/bin/sh' needed, but is provided
On Tue, 12 Feb 2019, Brian Reichert wrote:
First off, I have to admit that I'm uncertain if this is the
appropriate forum; I'd be happy for suggestions about where else
to look.
I'm doing this work on a stock install of CentOS-7-x86_64-Minimal-1810.iso,
with no updates.
I'm trying to create an RPM database from a custom set of RPMs.
One RPM ('openldap-ltb' from the LDAP Tool Box project (ltb-project.org)
has a dependency on '/bin/sh'. The bash RPM is demonstratedly
present, yet the the 'rpm' utility thinks this dependency is not
met.
I'm open to any advice as to how to progress.
I'm no expert on binary formats, but I think
openldap-ltb-2.4.47-1.el7.x86_64.rpm is broken. Try this against a
base rpm, e.g.,
rpm -q --requires -p ./cpio-2.11-27.el7.x86_64.rpm | od -c
warning: ./cpio-2.11-27.el7.x86_64.rpm: Header V3 RSA/SHA256
Signature, key ID f4a80eb5: NOKEY
000 / b i n / s h \n / b i n / s h \n
020 / s b i n / i n s t a l l - i n
040 f o \n / s b i n / i n s t a l l
060 - i n f o \n l i b c . s o . 6 (
100 ) ( 6 4 b i t ) \n l i b c . s o
Then run the same thing against the openldap-ltb package:
warning: ./openldap-ltb-2.4.47-1.el7.x86_64.rpm: Header V4 DSA/SHA1
Signature, key ID 6d45bfc5: NOKEY
000 / b i n / b a s h \n / b i n / s
020 h \n / b i n / s h \n / b i n / s
*
060 h \n / s b i n / l d c o n f i g
100 \n b e r k e l e y d b - l t b
That asterick where 040 (and its contents) should be is worrisome
to me. To my eye, something is amiss.
--
Paul Heinlein
heinl...@madboa.com
45°38' N, 122°6' W
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] weird RPM dependency error; '/bin/sh' needed, but is provided
On Tue, Feb 12, 2019 at 01:47:43PM -0800, Paul Heinlein wrote: > That asterick where 040 (and its contents) should be is worrisome > to me. To my eye, something is amiss. In the 'hexdump' and 'od' utilities, the '*' means a duplicate line was suppressed. From od(1): -v, --output-duplicates do not use * to mark line suppression To wit: $ rpm -q -requires -p openldap-ltb-2.4.47-1.el7.x86_64.rpm | od -c | head -5 warning: openldap-ltb-2.4.47-1.el7.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID 6d45bfc5: NOKEY 000 / b i n / b a s h \n / b i n / s 020 h \n / b i n / s h \n / b i n / s * 060 h \n / s b i n / l d c o n f i g 100 \n b e r k e l e y d b - l t b $ rpm -q -requires -p openldap-ltb-2.4.47-1.el7.x86_64.rpm | od -cv | head -5 warning: openldap-ltb-2.4.47-1.el7.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID 6d45bfc5: NOKEY 000 / b i n / b a s h \n / b i n / s 020 h \n / b i n / s h \n / b i n / s 040 h \n / b i n / s h \n / b i n / s 060 h \n / s b i n / l d c o n f i g 100 \n b e r k e l e y d b - l t b And indeed, for whatever reason, openldap-ltb lists '/bin/sh' several times: $ rpm -q -requires -p openldap-ltb-2.4.47-1.el7.x86_64.rpm | head -5 warning: openldap-ltb-2.4.47-1.el7.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID 6d45bfc5: NOKEY /bin/bash /bin/sh /bin/sh /bin/sh /bin/sh > > -- > Paul Heinlein > heinl...@madboa.com > 45?38' N, 122?6' W > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos -- Brian Reichert BSD admin/developer at large ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Cups Ink Levels
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? -- _ °v° /(_)\ ^ ^ Mark LaPierre Registered Linux user No #267004 https://linuxcounter.net/ ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] /boot partition running out of space randomly. Please help!
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! I am running the following kernel: 4.14.35-1844.0.7.el7uek.x86_64 Thanks! Sean S. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] /boot partition running out of space randomly. Please help!
On 13/02/19 2:05 PM, 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! I am running the following kernel: 4.14.35-1844.0.7.el7uek.x86_64 My stab in the dark is that the system is trying to write a crash / rescue image and there is not enough space. du --max-depth 1 is useful too. Thanks! Sean S. ___ 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] /boot partition running out of space randomly. Please help!
On Tue, Feb 12, 2019 at 9:39 PM Rob Kampen wrote: > On 13/02/19 2:05 PM, 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! > > > > I am running the following kernel: > > 4.14.35-1844.0.7.el7uek.x86_64 > My stab in the dark is that the system is trying to write a crash / > rescue image and there is not enough space. du --max-depth 1 is useful too. > > > > Thanks! > > > > Sean S. > > ___ > > 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 Hello Rob Thank you for the reply. What do you recommend I should do to prevent the crashing? Should I increase the /boot partition's disk space? I am worried that it will fill up again randomly like the current one is.. Should I create a new /boot partition? Thanks ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] DNSSEC Questions
Last weekend I had my DNSSEC keys expire. I discovered that they had expired the hard way... namely randomly websites could not be found and email did not get delivered. It seems that the keys were only valid for what I estimate was about 30 days. It is a real PITA to have update the keys, restart named and then update Godaddy with new digests. The first part of the problem is fairly manageable in the sense I already have a script that partially can do the job of updating the DNS server. However from what I can tell the only way I can update the DNSSEC of my 8 domains is via the Godaddy control panel GUI. So a couple of questions. 1.) Is anyone aware of anyway to update Godaddy DNSSEC data via a Centos 7 bash shell? I will contact Godaddy but I suspect I am SOL but thought I would ask here thinking somebody else may have already run into this issue. 2.) Assuming the answer to DNSSEC is no, can I at least have the keys last longer than they do by default. I am presently creating the keys via: > dnssec-keygen -a NSEC3RSASHA1 -b 2048 -n ZONE zone > dnssec-keygen -f KSK -a NSEC3RSASHA1 -b 4096 -n ZONE zone It is very unclear to me given the dnssec-keygen man page how to set the date so that I could get 90 days or even more per key. The descriptions I found about constructing rolling keys was even more cryptic to me. For example, how do you use these switches: -A date/offset Sets the date on which the key is to be activated. After that date, the key will be included in the zone and used to sign it. If not set, and if the -G option has not been used, the default is "now". -D date/offset Sets the date on which the key is to be deleted. After that date, the key will no longer be included in the zone. (It may remain in the key repository, however.) -I date/offset Sets the date on which the key is to be retired. After that date, the key will still be included in the zone, but it will not be used to sign it. -P date/offset Sets the date on which a key is to be published to the zone. After that date, the key will be included in the zone but will not be used to sign it. If not set, and if the -G option has not been used, the default is "now". -R date/offset Sets the date on which the key is to be revoked. After that date, the key will be flagged as revoked. It will be included in the zone and will be used to sign it. Is it as simple as setting the -I and -R switches to something like +90d At least if I can get the DNS server to update via a cron job even if the 1st item will always have to be done manually that would be help. Thanks for your help. -- Paul (ga...@nurdog.com) Cell: (303)257-5208 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] DNSSEC Questions
On 2/12/19 7:26 PM, Paul R. Ganci wrote: Last weekend I had my DNSSEC keys expire. I discovered that they had expired the hard way... namely randomly websites could not be found and email did not get delivered. It seems that the keys were only valid for what I estimate was about 30 days. It is a real PITA to have update the keys, restart named and then update Godaddy with new digests. 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. The first part of the problem is fairly manageable in the sense I already have a script that partially can do the job of updating the DNS server. However from what I can tell the only way I can update the DNSSEC of my 8 domains is via the Godaddy control panel GUI. So a couple of questions. 1.) Is anyone aware of anyway to update Godaddy DNSSEC data via a Centos 7 bash shell? I will contact Godaddy but I suspect I am SOL but thought I would ask here thinking somebody else may have already run into this issue. That I don't know, I use ldns to sign my zone files and upload them to my own authoritative nameserver. 2.) Assuming the answer to DNSSEC is no, can I at least have the keys last longer than they do by default. I am presently creating the keys via: > dnssec-keygen -a NSEC3RSASHA1 -b 2048 -n ZONE zone > dnssec-keygen -f KSK -a NSEC3RSASHA1 -b 4096 -n ZONE zone 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 It has switches for setting the start and expiration date of signatures. By default I believe it uses current timestamp for start and +60 days for end, though it may be +30 days. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] DNSSEC Questions
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. 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. 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? -- Paul (ga...@nurdog.com) Cell: (303)257-5208 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
