Re: [CentOS] Transition test report going from CentOS8 to Debian 10.
On 8/4/21 1:10 PM, Christopher Wensink wrote: Were these deployed on bare metal or as virtual machines? If Virtual were they on vmware? I have a mix of bare metal and virtual, but I am slowly migrating almost all of the bare-metal servers to virtualization. All of my production virtualization hosts here are now on Proxmox and are running the CentOS/Debian version mix guests in KVM. Still learning the tuning of Proxmox. Can anyone speak to how well a virtual machine will perform when being given 1 socket 1 core, vs. 1 socket 2 cores vs 2 sockets 1 core? I have not found any noticeable difference in whether a CPU is in a separate socket or just another core in one socket when using KVM virtualization. But I've also not done a deep-dive into benchmarking it, either, so I reserve the right to be wrong. This is with a mix of CentOS versions on a Proxmox host; all CentOS versions I've tried there have run well (and I have tried ALL major CentOS versions on Proxmox, including CentOS 2.1 through 5.) ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Transition test report going from CentOS8 to Debian 10.
On 2/4/21 10:39 AM, Lamar Owen wrote: ... I haven't decided whether to stay on Debian or not; too early to tell. . Six months on, and no longer too early to tell. I have found Debian to be minimally different from CentOS, in all actuality; much less different than transitioning to a *BSD would be. I've transitioned already deployed and configured production CentOS 8 machines to either Alma or Rocky (path of least resistance), keeping CentOS 7 machines on 7 until I need to revisit in 2023, and CentOS 6 machines went to Debian 10. Now, I'm going to say that the availability of both Rocky and Alma is a very good thing, and that availability made things a lot easier for a few already deployed production systems that needed to stay stable through the end of the year. New servers are being deployed on Debian 10; new virtualization hosts on Proxmox 6.4, although I am testing the Proxmox 6 to 7 upgrade path at one site and on my development hosts at the main site. Proxmox is SLICK. The upgrade path for simple servers from Debian 10 to Debian 11 is relatively simple, with a few caveats (no python 2.x in 11, so no Mailman 2.x, for instance). I have upgraded a few development servers from 10 to 11, and no issues were noted. Your mileage may vary, of course, but I've had a reasonably good experience with this transition. Thought I'd never say that; I've been a Red Hat user (partisan, even) for a very long time. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] almalinux?
On 4/5/21 12:20 PM, mark wrote: Anyone looked into almalinux? I was sort of waiting for rocky, but I see from over the weekend on slashdot that almalinux stable is released. I've cross-graded two C8 VMs over to AL8 and thus far smooth operation. I have NOT done any fresh installs (don't plan to, either, since new installs are all Debian now). Do note the release notes specifically mention that Secure Boot is not supported yet, so be aware of that if you use SecureBoot. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS-7-x86_64-dvd-2009.iso is too big for DVD blanks
On 3/18/21 10:23 AM, Stephen John Smoogen wrote: [what can be done] I am guessing someone could make an unofficial set of spins which cut out some packages to try and make it fit in single density. This is probably the solution at this point for the 'Full' DVD. In the interim, older machines such as this should just use the 'Minimal' DVD, since it fits on single-layer nicely. (I hear or read single-density and think FM encoding, 128 bytes per sector, 77-track IBM 3740 format 8 inch floppies..which are still in use in certain places...) Same for 8.x or 8 Stream -- oh, wait, there is no 'Minimal' ISO, so net install or USB is it, can't use optical media at all. You're right; we're rabbit-holing. Being at a non-profit, I have to rabbit hole a lot, since I tend to use much older hardware than 'normal.' ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS-7-x86_64-dvd-2009.iso is too big for DVD blanks
On 3/18/21 1:24 AM, John R. Dennison wrote: It's not realistic to expect server-class machines not to be able to boot from dual-layer or USB media in 2021. There are environments where USB or other writeable media are not allowed on premises. While all DVD-ROM drives are supposed to read DL media, in practice the compatibility has not proven to be 100%. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS-7-x86_64-dvd-2009.iso is too big for DVD blanks
On 3/16/21 9:37 AM, Lamar Owen wrote: Sure, no problem. I had a similar problem with a different version of CentOS, 8.3, which is too large to fit on a dual-layer DVD. I should have done the math before posting, sorry. Here's the math: lowen@d10-lo-m6700:~$ dvd+rw-mediainfo /dev/sr0 INQUIRY: [MATSHITA][BD-MLT UJ272 ][1.00] GET [CURRENT] CONFIGURATION: Mounted Media: 2Bh, DVD+R Double Layer ... READ TRACK INFORMATION[#1]: ... Free Blocks: 4173824*2KB Track Size: 4173824*2KB ... That's 8547991552 bytes. Ok: lowen@d10-lo-m6700:~$ ls -l CentOS*8.3*.iso -rw-r--r-- 1 lowen lowen 9264168960 Mar 16 09:27 CentOS-8.3.2011-x86_64-dvd1.iso lowen@d10-lo-m6700:~$ That's 716177408 bytes too large. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS-7-x86_64-dvd-2009.iso is too big for DVD blanks
On 3/15/21 5:04 PM, Stephen John Smoogen wrote: On Mon, 15 Mar 2021 at 16:26, Lamar Owen wrote: Well, what's odd is that the actual upstream RHEL 7.9 DVD WILL fit on a single-layer DVD. Just burned one. Well I am batting 0 for 1000 today. I am clearly not a good resource at the moment :). Thanks Lamar for checking the real source. Sure, no problem. I had a similar problem with a different version of CentOS, 8.3, which is too large to fit on a dual-layer DVD. I also had a similar problem with another product altogether, pfSense, which will no longer fit on a CD, even though the docs said 'CD/DVD image' and I was trying to repurpose an old server, 64-bit capable but very early 64-bit, that had a CD drive (parallel ATA thinline!) with a special connector, and I didn't have a DVD drive available. Oddly enough, that old box can boot USB, but only certain sticks, and so I used an old 1GB stick to boot pfSense on that box. I was prepared to boot an older pfSense and upgrade up to current. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS-7-x86_64-dvd-2009.iso is too big for DVD blanks
On 3/15/21 8:51 AM, Stephen John Smoogen wrote: Exactly that. Upstream Fedora and RHEL went to require dual density around Fedora 18, RHEL-7 because the amount of data was too much. Well, what's odd is that the actual upstream RHEL 7.9 DVD WILL fit on a single-layer DVD. Just burned one. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] How to install XFCE on CentOS 8?
On 2/26/21 11:38 AM, Leon Fauster via CentOS wrote: https://pagure.io/fm-orchestrator What an obvious package name. :-) Thanks for the pointer! ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] How to install XFCE on CentOS 8?
On 2/26/21 10:40 AM, Johnny Hughes wrote: From a user perspective or a building perspective? Builder. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] How to install XFCE on CentOS 8?
On 2/24/21 3:49 PM, Johnny Hughes wrote: Not that it matters .. BUT .. EL8 is much harder to build for. There are modular components, not all the Devel files exist, etc. It is much harder than EL7. And that difficulty shows; more stable perhaps, but many fewer packages. Is there a reference anywhere to how modularity is supposed to work? ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] How to install XFCE on CentOS 8?
On 2/11/21 11:18 AM, Nicolas Kovacs wrote: For the past couple years, my solution has been to use RHEL clones (CentOS and Oracle Linux) on servers only (multi-user.target). I've moved all my graphical installations (workstation, laptops, desktop clients) to OpenSUSE Leap + KDE. For a really long time I was pretty successful in running EL on both the desktop and the server. It HAS been getting way harder to do this. The EPEL, ELrepo, and RPMfusion repositories do a fantastic job overall, but there were way too many things missing from EPEL8 especially where the desktop experience was becoming a pretty sizable drain on my time building the packages I needed from Fedora. KiCAD and Sigrok were the toughest. I greatly prefer running the same OS version on my desktops and servers; makes management a lot easier. So this is part of why I am in the midst of evaluating a wholesale migration to Debian 10. On the server it works well, if somewhat different in setup; on the desktop it works so much better, with a huge and maintained repository, where I haven't had to dip into a PPA but once, and that was for a quick one-off package. It's in the virtualization arena where I am gobsmacked; I'm evaluating Proxmox, which is based on Debian 10, using the no-subscription repositories. Let me tell you, Proxmox has one more slick and highly integrated experience. Relative to running a KVM host with only the stock CentOS 8 cockpit and virt-manager, the Proxmox experience blew me away. I didn't realize just how much time I was spending finding third-party packages for EL8 until I didn't have to. Smooge, you know I feel your pain, but becoming a maintainer in EPEL has a pretty high bar (lots of new tools and methods to work with, amongst other things) -- as it SHOULD, given that it's intended as an addon to EL and needs to be very tightly controlled. It's just more difficult to get started these days relative to when anyone could build an rpm as long as they had a copy of Maximum RPM and knew how to drive 'rpm -ba' back when building as root in a non-reproducible buildroot wasn't a cardinal sin. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Transition test report going from CentOS8 to Debian 10.
On 2/5/21 2:03 PM, Warren Young wrote:
On Feb 5, 2021, at 9:03 AM, Lamar Owen wrote:
I consider this to be very minor in comparison to other items.
If you’re making a wholesale transition, sure, but when you’re maintaining a
mix of systems and you know what you’re trying to accomplish but can’t remember
the exact one of six different incantations for accomplishing that on the
platforms you maintain, it’s enough to frost one’s cookies.
...
(I mined that wiki to compose my prior reply. Real-world experience here.)
Not doubting your experience with your workloads, but my experience with
my workloads is different. I have had three CentOS major versions
running in parallel; as an example, our three internal recursive
resolver DNS servers were running three different CentOS versions for a
little while: one was C6, one is C7, and the newest is C8. The
different BIND versions are enough, but the {service|systemctl}
parameter order is the one that has caught me before. I too have notes,
and visual cues, and in the absence of those I'll look for unique
qualifiers; internal system names will typically have a version cue as
part of the name.
However, I’d prefer to hold tight to *one* bag of problems rather than gather
several bags of problems unto my bosom. :)
There are more than one set of issues going from C7 to C8, too. The
biggest for me was the removal of hardware support for older but very
serviceable servers (no, I'm NOT talking about the x330 P-III-S system!)
where Red Hat decreed by fiat that certain PCI IDs would not be
supported by their kernel even though the supporting driver IS in the
kernel (megaraid_sas is one of these); ELrepo to the rescue. But,
sure, having the smallest set of surprises is a good thing. Documenting
the surprises I found is part of the reason I posted this in case
someone else were to try this same transition. But I am NOT saying that
this will be the best choice for everyone.
And realize that firewalld is just an example, not the full scope of the
problem. Solve that one across platforms, and you’ve got several more to deal
with next.
Of course I know firewalld is just one example; there's always something
new to deal with; I just found the switch to not be as hard as I feared
it would be, that's all. I found it to be comparable for my workloads
so far to the C7->C8 transition, and not as difficult as going from C6
-> C8, especially on a workstation.
If migrating from CentOS I would probably go with firewalld. I haven't decided
yet in my evaluations. But I put an ACL on the Cisco 7609's here
How does fobbing the problem off on Cisco help in today’s “deny everything by
default” world?
The Cisco ACLs were already there, pretransition, deny by default; I've
been doing 'deny by default' for right now 25 years since the days of
IOS 10 on 2500-series gear. It's not something I put in place because I
didn't have a host-side firewall in place; but I can see the way I wrote
my statement could imply that I just threw an ACL up on a handy Cisco
instead.
...you’ve now got to learn to do that on every platform you’re supporting,
because it probably won’t be the same way on any two of them.
Already happening; pfSense and Cisco IOS are both involved, and have
different ways of doing the same thing. Six of one; half a dozen of
another; there's no 'probably' to it, it is guaranteed to be different,
even on two products from the same company like Cisco (like the
difference between 'show mac-address-table ' on one platform and
'show mac address-table' on another; Cisco IOS dialectal differences can
be much much worse than Linux distributions' dialectal differences).
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Transition test report going from CentOS8 to Debian 10.
On 2/5/21 11:32 AM, m...@tdiehl.org wrote: Hi, On Thu, 4 Feb 2021, Warren Young wrote: ... 1. The package names are often different, and not always differing by an obvious translation rule. ... Yep!! It is a pita when trying to get things running for the first time. I started this journey on a couple samba DC's before the Red Hat announcement. Libraries are almost always different names but even common packages like dhcp and bind have different names, configuration files and commands to do the same thing. Most of it is not that hard to figure out but it does take time to do it and it is a lot more work than going from CentOS 7 to CentOS 8. ... Maybe I'm just weird, but I don't find naming differences to be big differences. Like I keep telling optical astronomers, radio astronomy is just observing at another wavelength; I get a lot of mean looks when I say that, too. It's all light, why are humans so special that our three sensory passbands centered around 450nm, 540nm, and 575nm should be so important? Why is the 400nm-700nm band more important than say 1000nm to 1700nm other than human eyes' sensitivities? Package naming is syntactic sugar, no more and no less, IMHO. Their systemd implementation is my biggest problem with Debian based systems. ... It would be nice if they would make up their minds. Either bite the bullet and convert everything to systemd or stay with sysv :-( One of the contrasts between Debian and many others is the complete governance transparency. In December 2019 they (where 'they' is the collective group of Debian Developers only, not users) voted on this issue; the process and results are documented here: https://www.debian.org/vote/2019/vote_002 In a nutshell, Debian moved closer to focusing entirely on systemd; people interested in alternatives have to provide the tooling and work themselves. Looking in unstable should show the current state of the systemd integration; stable is too old to reflect this vote. So I would expect Bullseye (Debian 11) to have a more integrated systemd. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] letsencrypt error
On 2/5/21 10:00 AM, Jerry Geis wrote: I thought someone would have ran into the same issue as I was migrating to this new way of doing things getting letsencypt working on apache. I did run into it, just on nginx. That's why I posted the reply. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Transition test report going from CentOS8 to Debian 10.
On 2/5/21 11:21 AM, Nicolas Kovacs wrote: Le 05/02/2021 à 17:03, Lamar Owen a écrit : I thought long and hard about it before posting to the CentOS lists, because I don't want to be perceived as advocating for a particular transition path. I found your post highly interesting, even though I chose a different path: https://blog.microlinux.fr/migration-centos-oracle-linux-cas-pratique/ Thanks. I am a firm believer in having options, and for CentOS 8 early adopters there are options available; each user just needs to get informed about them and make the informed choice that is necessary. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Transition test report going from CentOS8 to Debian 10.
On 2/4/21 1:23 PM, Warren Young wrote: On Feb 4, 2021, at 8:39 AM, Lamar Owen wrote: I posted a pretty complete rundown on the scientific linux users mailing list, so I won't recap it all here. Link? Yeah, I forgot to post the link... sorry about that. Akemi beat me to it, so I'll not repost. Thanks, Akemi! the transition was not any more difficult, really, than moving from CentOS 7 to CentOS 8. That’s not my experience. I thought long and hard about it before posting to the CentOS lists, because I don't want to be perceived as advocating for a particular transition path. I am exploring different paths, and I started with my own workstation. Of course workstation needs are going to be some different than server needs; and thus I posted here to sincerely see others' experiences. Thanks for the great information! I keep several of my packages running on CentOS and Debian (and more) and I keep running into several common problems: 1. The package names are often different, and not always differing by an obvious translation rule. ... This one I've run across, and yes the package name differences are annoying. I did some cross-packaging myself back in the day, all on RPM systems, and I had to do special cases for SuSE since the package names are quite different there, too. Why are they different? Different naming standards developed at different times by different people with different ideas; I would consider it very odd if different distributions had identical package naming after going through such different paths. I consider this to be very minor in comparison to other items. 2. Some packages simply won’t be available. Most often this happens in the Debian → CentOS direction, but I’ve run into cases going the other way. ... Yes, true. True going from C7 to C8, too, especially if you rely on third-party repositories for packages. 3. Debian adopted systemd, but it didn’t adopt the rest of the Red Hat userland tooling. For instance, it’s firewalld on CentOS, UFW on Ubuntu, and raw kernel firewall manipulation on Debian unless you install one of those two. And then, which? That one is more serious for the server than the other two, for sure. If migrating from CentOS I would probably go with firewalld. I haven't decided yet in my evaluations. But I put an ACL on the Cisco 7609's here on all server-bound traffic, so not yet an important consideration for me. But it will be soon enough. 4. Network configuration is almost entirely different unless you turn off all the automation on all platforms, in which case you might as well switch to macOS or FreeBSD for all the good your muscle memory and training will do you. Again I started with my workstation, and since I chose a GNOME install I got all the NetworkManager tooling; once NM is in control there aren't too many differences. Red Hat and Debian chose different paths for system configuration information, that much is for sure. But I try to not EVER use strict muscle memory in a sysadmin role, since that is guaranteed to break on CentOS version upgrades too, and I have too many different systems to rely on muscle memory, although I do find myself using that out of habit. Constantly doing things differently keeps me sharp, hopefully, at least. YMMV. I’m not saying “don’t do it,” but to say it’s as smooth as from CentOS 7 to 8? Hard sell. On my workstation with my workload it hasn't so far been that big of a deal and was less of a hassle than what C7 to C8 was; that is my specific workstation and my specific workloads, of course. I am getting ready to take an older internal server that is on CentOS 6 (yes, I know, EOL etc etc) to Debian 10 as a test; I had planned to take to CentOS 8 in early December, at least until the news hit, causing me to hold it up until I had a better idea of the issues. I'll know a whole lot more after that is done. ... it’s always *something.* True that. I will say that thus far my experience is mostly on the workstation, although I did set up a couple of test servers. One is an old Dell PE1950; had no issues with the Red Hat-unsupported Dell PERC RAID controller and the C8-removed PCI IDs from the megaraid_sas driver. The other one is... well, INTERESTING: for grins and giggles I installed the 32-bit version on an ancient IBM eSeries x330 rocking dual Pentium III-S 1.4GHz Tualatins with a full 4GB of RAM and dual 146GB U320 SCSI drives - maximum performance you'll get from a Pentium III (and almost as good as a much newer 64-bit Netburst-based Xeon at 3.2GHz; Byte Unixbench on the Tualatins at 324.6; on the Noconas 491.4, at over twice the clock speed, too). And it's fun to just be able to say I have one of the most maxxed-out Pentium III-S systems you'll find, at least without overclocking or going past a dually. YMMV, and you might not think it so much fun, but you'll see my idea of computer fun
Re: [CentOS] letsencrypt error
On 2/5/21 7:49 AM, Jerry Geis wrote: *>>certbot-auto is no longer available. See https://certbot.eff.org/docs/install.html#id9 "We used to have a shell script named certbot-auto to help people install Certbot on UNIX operating systems, however, this script is no longer supported. If you want to uninstall certbot-auto, you can follow our instructions here." ... Skipping bootstrap because certbot-auto is deprecated on this system. Your system is not supported by certbot-auto anymore. Certbot cannot be installed. Please visit https://certbot.eff.org/ to check for other alternatives. My Centos 7 is basically out of the box. Previously with certbot-auto - it worked every time. Any one else run into this and know what the issue is ? The issue is fully documented and is simply that the certbot-auto script is being discontinued by the certbot team at EFF. Questions about why it's being discontinued would need to be taken up with the EFF team on their github issue tracker at https://github.com/certbot/certbot/issues The EFF-recommended way to use certbot has changed. The _new_ way is with a snap (as in 'install snapd and download the snap for certbot'). If you already have it might work, but that's going away; you need to use the solution recommended at certbot.eff.org which first instructs the user to uninstall any OS package containing certbot. At https://certbot.eff.org/docs/install.html there is a warning block: "While the Certbot team tries to keep the Certbot packages offered by various operating systems working in the most basic sense, due to distribution policies and/or the limited resources of distribution maintainers, Certbot OS packages often have problems that other distribution mechanisms do not. The packages are often old resulting in a lack of bug fixes and features and a worse TLS configuration than is generated by newer versions of Certbot. They also may not configure certificate renewal for you or have all of Certbot’s plugins available. For reasons like these, we recommend most users follow the instructions at https://certbot.eff.org/instructions and OS packages are only documented here as an alternative." Further, this isn't a CentOS problem; CentOS 7 doesn't ship certbot-auto. EPEL7 ships a certbot package, but it doesn't ship certbot-auto. The certbot in the EPEL7 package is currently working on one of my systems, but it is at this point in time one release out of date. (the package currently in EPEL7 is 1.11.0; current is 1.12.0; 1.12.0 drops support for python2, so the move from 1.11.0 to 1.12.0 could be fun). So, the EFF's recommended instructions for CentOS 7 running nginx are at https://certbot.eff.org/lets-encrypt/centosrhel7-nginx (I chose the nginx page because I am running some servers with CentOS 7 and nginx; there are instructions for CentOS/RHEL 8 as well as for apache). ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Transition test report going from CentOS8 to Debian 10.
Sorry for the length I'm posting this here since this particular transition has been mentioned on-list as one possibility for a path forward for current CentOS Linux users. AlmaLinux, the Developer Subscription RHEL, Rocky, CentOS Stream, Springdale, upgrading to full RHEL; all these are also possibilities, too, and all have different strengths and weaknesses. The transition to Debian has a lot of strengths, including a long track-record of support (even if the support time for a particular release is shorter), a fully-open development model with no 'corporate overlord' that I know of, a large set of supported packages, and a huge community of developers and users. For the CentOS user the main weakness is having to learn a few areas of difference in the way the system is setup and maintained; of course, if a ten-year 'stable' timeframe is really that important to you the lack of that is also a weakness. So, last week I transitioned, as a test of sorts, my working CentOS 8 main laptop to Debian 10. I kept a complete backup of the C8 install should I wish to go back to it, and installed Buster to a new mSATA SSD, but ported the two SATA drives (Dell Precision M6700 - has an mSATA slot plus two SATA bays) straight over after making full backups. I posted a pretty complete rundown on the scientific linux users mailing list, so I won't recap it all here. The bottom line was the the transition was not any more difficult, really, than moving from CentOS 7 to CentOS 8. The software versions in Buster are pretty close to what is in CentOS 8, although I have yet to need any third-party repository (PPA) for anything I've needed to install. All the packages I have worked with so far have worked fine with a little bit of massaging. These include commercial (and costly) software such as Harrison Consoles' Mixbus32C, Qoppa's PDFStudio2019 Professional, and others. So if you were to decide that this is the route for you to take, it does work and I found it to be not nearly as hard as I had thought it might be. If you install GNOME 3 you get GNOME 3; it feels pretty much the same as a non-Classic CentOS GNOME 3, just with a different set of extensions installed by default. That's on the workstation. On the server side, I'm evaluating Proxmox for the virtualization solution, and so far I'm finding it to be a pretty easy migration. I'm using the 'non-subscription' repository, so this is a no-cost option. Even getting the box registered to our EMC Clariion SAN was relatively easy; EMC provides the Unisphere Server Utility for Linux x64 in RPM form; the latest I have is "ServerUtil-Linux-64-x86-en_US-1.0.55.1.0044-1.x86_64.rpm" (which is fairly old, but I did say Clariion arrays, so they're pretty old, too). Debian has provided the 'alien' tool for some time; after installing alien, a simple 'alien -i ServerUtil-Linux-64-x86-en_US-1.0.55.1.0044-1.x86_64.rpm' installed the EMC RPM in the correct place. Proxmox already included everything that serverutilcli requires; on a plain Buster install I had to install dm-multipath and the device mapper libraries and tools before serverutilcli would find the arrays; but it ran just like it did on CentOS 8 (and 7). I haven't decided whether to stay on Debian or not; too early to tell. I have time to test and evaluate. My CentOS 7 installs aren't goin anywhere, though, at least until late 2023. And I've registered for a Developer subscription of RHEL so that I can properly evaluate that option, too. This is the beauty of open source: we have OPTIONS. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] RHEL changes
On 1/21/21 5:50 PM, Nicolas Kovacs wrote: Debian has an average of two years[*] per support. Oracle has ten like upstream RHEL. Choice is pretty clear to me. [*] one year after subsequent release, so an average of one to three years depending on installation date So, I want to address the "ten years of support" albatross. On the surface, ten years of support sounds like a big win; it certainly did to me back when it was first introduced. I have found that the reality is far more nuanced than that. I have found in my own career that the "ten years of support" argument has made me lazy in keeping up with newer technologies and methodologies, stagnant in my own server and workstation deployments, and increasingly frustrated once the five-to-seven year point has passed in what I can't do or can't build because "ten years support! Stability! Stability! Stability at all costs!" For my uses and purposes, Fedora's six month cycle is too fast (I've been on that roller coaster before, no desire to go back to it). CentOS Stream's continuous release cycle is too fast, especially in the kernel ABI department. I believe that, for my uses at least, a two-to-five year cycle is going to be the sweet spot. And the fact of the matter is that CentOS and the ten-year cycle isn't nearly as stable as you might first think; install CentOS 7.0 on a test VM and carefully compare to 7.9, especially on the workstation side with Firefox and Thunderbird! Further, when it's budget time, updating stagnating services running on a stagnant OS becomes an easy mark for cutting from the budget, because "ten years!" - until those ten years are over and you find out that you've just delayed all the effort into one lump instead of spreading it out a little bit each year or two (or three to five). But ten-year stagn^H^H^H^Hupport also makes me less marketable if I were to need to change jobs, especially if that ten-year stability has calloused my learning skills to the point that I feel personally threatened by major changes to, say, the init system underneath everything. So, in my career, I'm not sure relying on ten-year support has been a good thing. YMMV as I'm sure there are places where ten years of support really is critical; just not for me. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] RHEL changes
On 1/22/21 9:10 AM, Stephen John Smoogen wrote: My guess is that no one wants to go to a new OS alone. They want to go with all their mailing list buddies but they also want to make a STATEMENT to stick it in the eye of Red Hat for doing this. Going to a staid and quiet existing OS doesn't make that statement. Going to a competing company like Oracle does have the stick in the eye, but it already has its own community and ways of doing things in an Oracle way. Well said. The 'in your face!' attitude of 'sticking it to The Man' is pretty juvenile. I'm going to be transitioning to the most staid and quiet of those choices myself. It will be like starting over from scratch in terms of community, and at this point in my career I think that's ok. If the need were to arise like it arose for me back in 1999 when I stepped up in Red Hat Land to maintain the upstream PostgreSQL RPMs then I would step right in as a newcomer and build a reputation in that community. There's something to be said for starting from scratch with a nearly new reputation; while your successes won't follow you, neither will your failures! ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 8 future
On 12/16/20 5:09 PM, Johnny Hughes wrote: Hi Lamar, glad to interact w/ you on the list. We both have been doing this for a long time. Yes, indeed. (Xenix V7 on a TRS-80 Model 16 in 1988..., I STILL use my vi skills from that time i my life!) I was not thrilled about this decision and it would not have been the one made if things were up to me alone. Obviously they are not. I did support the issue from the perspective of the CentOS Board. Sometimes we have to make hard decisions in life. Many times, one wishes for another option. I do think I chose the best option available. ... Yes, how true. Been there, done that, on a much smaller scale. ... People can contact (via email) centos-questi...@redhat.com ... Other than it is one of the things the CentOS Board negotiated for before our vote. Thanks for the pointer. I see I have some writing to do. And thanks for pushing for that feedback mechanism! ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] I'm looking forward to the future of CentOS Stream
On 12/14/20 10:52 AM, Phelps, Matthew wrote: ... The main issue against using Fedora in production environments is the short lifecycle. Forcing an upgrade, and all the associated testing, auditing, etc. of the base version every year or so is not tenable for most organizations. Indeed. Fedora kernels also have no KABI stability for third-party drivers; every kernel update carries the potential for breakage. At least you're not trying to track and run Rawhide. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] I'm looking forward to the future of CentOS Stream
On 12/13/20 3:25 PM, Dave Stevens wrote: On Sun, 13 Dec 2020 21:05:42 +0100 Rainer Duffner wrote: It’s also not often the case that you can split this kind of work into a thousand work-packages and have everybody just work 1/2 hour a day on it. not like Debian for instance No, not at all like Debian. Debian doesn't have to try to match the unattainable goal of 100% binary compatibility with an upstream source. I've seen a small part of this first-hand, and deducing the build order to gain binary compatibility is the one thing that can single-thread the build process quicker than anything else. RHEL doesn't even have the same need; an RHEL rebuild that didn't have the goal to be bug-compatible near the 100% level doesn't, either, and can be built by a lot of people. Try it yourself: go back to CentOS 5.5 and attempt to rebuild the released sources for 5.6 and get a binary compatible build. I've done it myself for IA64; it was a pain. All of the upstream distributions, Debian, Fedora, etc, have a lot of latitude that CentOS never has enjoyed. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 8.3 bugs
On 12/17/20 11:59 AM, Johnny Hughes wrote: The compose takes place on pungi and the process has several config files, etc. Composing CentOS Linux 8 is significantly differ than other releases, and it is more complicated. We do fix things as soon as we see them. Glad to see net-snmp-perl back in the main distribution. Now I don't have to rebuild my own loacl copy out of git, although it was a good learning opportunity to do so. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Blog article: CentOS is NOT dead
On 12/14/20 10:54 AM, Yves Bellefeuille wrote: The article states that CentOS will now be "upstream" of RHEL instead of "downstream". This is strange to me. I never thought CentOS was upstream or downstream of RHEL; I always thought it *was* RHEL -- perhaps a little delayed, but that's not the same as being "downstream". CentOS has always been 'downstream' of RHEL. The CentOS team rebuilt the source packages with the goal of getting as close as possible to what RHEL shipped, but it has never been 100% identical. You can do the same by pulling all of the package contents from git.centos.org and build the sources in the correct order with the correct software and the correct options to rpmbuild. Building from git.centos.org is not really hard at all; what is hard is figuring out the order and figuring out the other bits you might need that aren't necessarily on git.centos.org. Building from git is documented at https://wiki.centos.org/Sources?highlight=(git.centos.org) and you can look at an example of how I rebuilt a CentOS 8 RPM to get a non-distributed subpackage rebuilt at https://forums.centos.org/viewtopic.php?f=54=73376=314200#p314200 CentOS has never *been* actual RHEL. It's also clear that Red Hat didn't understand the importance of the 10-year support period. If they didn't understand it, they wouldn't offer it for RHEL. They just believe that if you need that you should pay something for it. A 10-year support lifespan, even doing a straight rebuild of the packages from RHEL, has a huge cost, and someone has to pay those costs. Should Red Hat's paying customer base subsidize those costs? (if you say 'Red Hat should pay for it' that actually means you think Red Hat's paying customers should pay for it, because that's where Red Hat's money comes from). In the case of Oracle Linux, Oracle has decided that yes, their paying support customers should subsidize the cost for those who aren't paying. Someone, somewhere, must pay the costs; in a volunteer project the volunteers typically pay the labor cost themselves, and in many cases pay the cost of the compute hardware, bandwidth, and electricity required; these are not small costs, and someone, somewhere, must pay them. If the costs aren't adequately covered, the project's deliverables suffer, and users complain. It really just boils down to a cost without a tangible return on investment. It remains to be seen if the intangible ROI was as large as the vocal reaction to the transition announcement would imply. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 8 future
On 12/16/20 10:50 AM, Johnny Hughes wrote: Why did they change the development process of RHEL .. Because they want to do the development in the community. The current process of RHEL development is closed .. they want it to be open. It is that simple. Johnny, let me say first of all thanks for these years of hard work. I for one am grateful for your continued and dogged pursuit of what must be a mostly thankless task. Thanks for the explanations from your point of view of this transition, too. Having said that, I believe that in terms of RHEL development and transparency that CentOS Stream will be a very big win. With working resolutions to the 'unsupported by Red Hat but not third-party out-of-tree driver kABI breaks frequently' and 'third-party out-of-tree hardware driver kABI breaks frequently' issues I'm sure it can be a very usable system for what I need CentOS for. And it will be very nice to be able to have actual feedback that might actually make a difference in the development of each next point release. That will work nicely for my main daily driver laptop. Maybe or maybe not for my servers; that has yet to be seen. But as I posted in my reply to Mike McGrath, Red Hat's reneging on the September 24, 2019 statement that "nothing changes" for CentOS, especially CentOS 8, still smarts. A lot. (I know it must be worse for you and the other devs.) ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] What are the differences between CentOS Linux and CentOS Stream?
On 12/16/20 12:55 PM, Ljubomir Ljubojevic wrote: Off-topic: On 12/16/20 4:11 PM, Lamar Owen wrote: 2.) The enthusiasts who were building their own machines from parts. That group is small, but they also tend to be very vocal; IT professionals often fall into this group, and MS wanted to keep them happy for all the reasons previously posted. In less developed countries PC's are sold without any software, even laptops. ... Since it is illegal to install pirated software, PC resellers are not allowed to preinstall pirated software, but no one can prevent them to sell it without any OS/software on it, so 70-80% of PC's sold in Serbia are sold without it. Similar is in many countries outside of "Western countries". It is certainly different in different countries; I can only speak for what I see in my own area. I don't see a lot of new PCs sold without some license of some kind; Dell Precision workstations and PowerEdge servers are available with Linux preinstalled, and PowerEdge servers can be purchased without any OS. Most PC manufacturers here have deals with Microsoft to prevent them selling PCs without OS. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] What are the differences between CentOS Linux and CentOS Stream?
On 12/16/20 11:24 AM, R C wrote: On 12/16/20 8:11 AM, Lamar Owen wrote: But the Red Hat-based ecosystem version of that second group is on-topic, as the same sort of enthusiast exists here and has been very vocal about this change. Well yes it is, but it started with a remark about licensing. I don't use Windows much, not even a handful of times in the last decade. Thing is that MS has something called their "Developers Network" (named something along those lines). If you're in higher education, R etc you can be in that network, in sortof an R category, for 'free'. ... I have a whole shelf full of MSDN CDs and binders; it wasn't free, but it wasn't terribly expensive either. In some cases the activations/keys for the software expire after a few months. Still have the last Windows 2000 Beta CD for the DEC Alpha architecture here in that set. Something similar for RHEL beyond the single-entitlement developer subscription would be cool. For example, I was messing with kubernetes in a few ways. redhat provides a license for RHEL, that you can use for that purpose for free, BUT you can have only have one license. Yes, which makes it a bit difficult to mess around with kubernetes. That particular case would be covered resonably well by CentOS Stream, though, since the major part of kubernetes' behavior isn't going to change radically within a point release cycle. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] What are the differences between CentOS Linux and CentOS Stream?
On 12/15/20 1:24 PM, R C wrote: What I meant was that MS basically, for the longest while, had their OS pre-installed on computers sold, so it "felt" free to the buyer, it came with the machine. Universities and colleges did receive bulk licenses and .NET pretty much for free in their 'Developer Programs' and also have students keep using it. That "faillure to implement" obviously was a marketing move indeed, as was students "allowing" to keep using it on their laptops after graduation. This is way off-topic, but there are two aspects of home users using unlicensed copies of Windows: 1.) Users who bought a machine with Windows Home Edition on it who wanted either Professional or Ultimate; 2.) The enthusiasts who were building their own machines from parts. That group is small, but they also tend to be very vocal; IT professionals often fall into this group, and MS wanted to keep them happy for all the reasons previously posted. But the Red Hat-based ecosystem version of that second group is on-topic, as the same sort of enthusiast exists here and has been very vocal about this change. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 8 future
On 12/12/20 10:34 PM, Konstantin Boyandin via CentOS wrote: My only concern ATM is whether RH can change its CentOS 7 maintenance plans as well, all of a sudden. This is what bothers me, too, but in a slightly different way. Even for the GPL software, Red Hat actually doesn't have to provide public access to the source code; the only thing required by GPL is that those who receive binaries must be able to get sources. So, even though it has been said that the source will be available, well, it was also said that C8 would be supported to 2029. There are enough packages in RHEL with non-GPL licenses where it would be very difficult to rebuild the whole distribution without them, and RH is not required by those licenses (MIT, BSD, and others) to redistribute those modified sources even to people who have been distributed binaries. So, while I want to believe that the sources will remain available, that belief relies on trust, which unfortunately is less abundant these days. So while using another rebuild seems to be a good stopgap solution, I do wonder if it will prove to be sustainable post-2021. I'm personally looking at which of the four (that we know about) to possibly go to; I just really doubt I am going to use Oracle; Rocky isn't really there yet and is very young; Springdale is available, mature, and academically supported (nothing wrong with that, just a statement); CloudLinux OS Project Lenix isn't yet released. Out of the bunch, Springdale would be my first choice right now because it's been around a very long time and is available now. C8 is supposed to be around until end of 2021, so there is some time for the dust to settle and the way to become more clear, though. But CentOS 8 Stream is only an option for me if the hardware driver KABI synchronization issue is solved and stays solved. RHEL? Under the current subscription models we just can't afford it. (Cost also keeps SLES out of the running.) But I'm now seriously considering just simply going to something that is both older than Red Hat, fully and totally open, extremely well-supported by a diverse developer community, and used by a whole lot of people. Yes, that's Debian; until I realized where the name came from (Deb and Ian) it read to me like a play on 'deviant.' The 'stable' period is shorter, for sure. The tradeoffs are pretty simple: guaranteed openness versus less change for ten years. So, let's look at that last piece. CentOS 6's support just ended; what have the last nine years and three months of actual C6 support looked like? I supported several C6 machines, and there were distinct challenges early on, at least for the first four years or so. Since then, on the server, it's been very stable, but really old; key pieces of infrastructure software we use slowly became unusable on C6 due to the old versions of specific packages, and either a third-party repo with newer packages or a newer CentOS was needed. Third-party repos have improved over the years, but some of the earlier C6 machines I installed had packages from Linuxtech, Dag, ATrpms, City-Fan (one particular DVD burner that just had to have the non-wodim cdrtools for some reason; yes, I know all the warnings about that repo), and others. Having EPEL and Dag both package a few things that I needed, but package them differently, introduced me to package pinning and repo priorities I don't miss those days. Seriously stable in the core repos means very little when you need much less stable third-party repos to get actual work done. That's also why Fedora isn't really an option, just too much package churn; been there, done that, a few years ago. So I've started re-evaluating just why I use CentOS anyway; the answer really boils down to the fact that I started out with Red Hat Linux in 1997 (I live in North Carolina, and I've always liked supporting local companies) and I just really don't want to change; it feels like I've wasted so much effort if I change now (that was the reason I stuck with it through the Fedora-RHEL split years ago, too, and went with a RHEL rebuild, first WBEL then CentOS). But the reality is not nearly so stark; a vast majority of the information and skills I've picked up in these years are portable to other distributions; so it's not wasted effort. Well, other than RPM packaging skills; those are a bit less portable. Whenever I've built from source I've tried to either build my own RPM for it or rebuild the Fedora RPM for it, and so I have a local repo of those packages, making reinstall much easier. So it becomes a tossup: small change to another rebuild now, possibility of major change later, or bite the bullet and go ahead and get the major change over with and only have small changes later. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 8 future
On 12/11/20 9:51 PM, Yves Bellefeuille wrote: I'm most disappointed with the silence from Karanbir and friends. Obviously their Red Hat salary is more important to them than keeping CentOS the way it was. :-( This boggles the mind. OF COURSE their salary should realistically be more important to them than keeping CentOS the way it was; how strong of a disagreement with your employer is your salary worth? However, reading between the lines, with Red Hat's internal developers directly working with CentOS Stream beginning 1Q 2021, and CentOS 7 ending support in 2024, I have to wonder a little what the long-term employment of those building CentOS looks like, specifically post-CentOS 7 EOL. Of course, it's not really any of my business, to be honest, but the CentOS developers are all very bright and highly skilled, so they are very employable, whether at Red Hat or elsewhere. Given what's already been posted to the lists, it seems to me that the CentOS Board was able to obtain some concessions; I will likely never know what those were, nor is it really any of my business what they were, but I thank the CentOS Board for doing what they could. And I thank all those who have built and continue to build CentOS; I've had a relatively small exposure to what building and distributing packages is like, a few years back (well, 1999 to 2004), and user-entitlement-syndrome is part of the reason I won't do that any more (my wife's health was the primary reason I stopped, though; priorities are priorities!). ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] https://blog.centos.org/2020/12/future-is-centos-stream/
On 12/9/20 9:37 PM, Akemi Yagi wrote: On Wed, Dec 9, 2020 at 6:07 PM Lamar Owen wrote: So, I want to address this part a bit. In MANY cases, it's not a third-party driver that ELrepo packages; it's an in-kernel driver that Red Hat has decided to disable. Such as the megaraid_sas driver I need for my servers. And just to give you some more examples -- ELRepo offers DUD (driver update disk) images for the devices whose support has been dropped in RHEL 8: https://elrepo.org/linux/dud/el8/x86_64/ And those DUDs are very much appreciated. That's how I got the install of C8 on those R710s in the first place, after all! ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] https://blog.centos.org/2020/12/future-is-centos-stream/
On 12/9/20 12:10 PM, Brendan Conoboy wrote: While I'm not sure how we'll get there, it seems like the mutually satisfying end result would be one where third party binary drivers work with CentOS Stream kernels. Let's see what we can do. So, I want to address this part a bit. In MANY cases, it's not a third-party driver that ELrepo packages; it's an in-kernel driver that Red Hat has decided to disable. Such as the megaraid_sas driver I need for my servers. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 7 shim fix failed
On 8/5/20 5:40 AM, Kenneth Porter wrote: Is there some way we could get the initrd rebuild to be more verbose, so that it doesn't appear to hang? It would be nice to get feedback that something is happening, especially on an older, slower system that takes a long time for this step. While the process CAN be made more verbose, it won't help any. RPM scriptlets are actually not supposed to generate output; both rpm and yum (and by extension dnf) buffer scriptlet output so that any messages that are issued will all be seen after the entire scriptlet has run. The same thing is true for say the ELrepo kmods, such as kmod-nvidia. That rpm needs to rebuild the initrd, and even issues a message saying something like 'this may take a while' or similar, but you won't get that message until the scriptlet doing the initrd rebuild has finished. This is one area I think the Debian packaging system is a bit superior, in that dpkg's can issue progress reports and similar. But rpm has been this way for a really really long time, ever since I maintained the PostgreSQL RPMset from 1999 to 2004. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Fixing grub/shim issue Centos 7
On 8/4/20 2:31 AM, lpeci wrote: 3) Config network: 3.1) # ip addr add X.X.X.X/X dev X 3.2) # ip route add default via X.X.X.X <--- default router While I appreciate the thoughts behind this step in the instructions, and I thank you for the post that will be useful to those running fairly traditional servers, there are numerous cases where this simply will not work to bring up a network while booted into the rescue mode chroot. Not all, and maybe not even most, CentOS machines are traditional servers with simple direct ethernet connections that don't require more steps. I can just off the top of my head think of three cases where the above won't work: Case 1: Virtualization host with a bridge on multiple VLANs over a bond. Depending upon the type of bond, it may or may not be possible to bring up the host's interface to the network with the commands above. More than half of my server machines here fall under this case. Case 2: workstation with wired network and 802.1x authentication. Case 3: workstation or laptop with only a wireless interface that requires a supplicant to authenticate. Yes, workstation and laptop installs of CentOS do exist and are actively used and are just as important to recover as any traditional server. For my laptop I was able to recover thanks to the 'nmtui' text-mode interactive interface to NetworkManager, bringing up any of my WiFi SSIDs with authentication; if any of my virtualization hosts had hit this problem (none did, interestingly enough) nmtui would have allowed me to activate the bridge on the host admin vlan quickly and easily from, again, a nice interactive text interface that is dead-simple to use quickly and accurately, and where you don't have to do any extra steps to get the interface name or any other details; nmtui just takes care of it in an intuitive manner. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] 8.2.2004 Latest yum update renders machine unbootable
On 8/1/20 11:02 AM, Lamar Owen wrote: ... [lowen@localhost ~]$ rpm -qa | grep ^kernel|grep 147 kernel-devel-4.18.0-147.8.1.el8_1.x86_64 kernel-4.18.0-147.8.1.el8_1.x86_64 kernel-modules-4.18.0-147.8.1.el8_1.x86_64 kernel-core-4.18.0-147.8.1.el8_1.x86_64 [lowen@localhost ~]$ Well, I sure fat-fingered that command let's try it again: [lowen@localhost ~]$ rpm -qa | grep ^kernel|grep 193.14 kernel-headers-4.18.0-193.14.2.el8_2.x86_64 kernel-devel-4.18.0-193.14.2.el8_2.x86_64 kernel-modules-4.18.0-193.14.2.el8_2.x86_64 kernel-tools-4.18.0-193.14.2.el8_2.x86_64 kernel-core-4.18.0-193.14.2.el8_2.x86_64 kernel-tools-libs-4.18.0-193.14.2.el8_2.x86_64 kernel-4.18.0-193.14.2.el8_2.x86_64 [lowen@localhost ~]$ uname -a Linux localhost.localdomain 4.18.0-193.14.2.el8_2.x86_64 #1 SMP Sun Jul 26 03:54:29 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux [lowen@localhost ~]$ ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] 8.2.2004 Latest yum update renders machine unbootable
On 7/31/20 6:35 AM, Alan McRae via CentOS wrote: I am running an Intel x64 machine using UEFI to boot an SSD. Installing the latest yum update which includes grub2 and kernel 4.18.0-193.14.2.el8_2.x86_64 renders the machine unbootable, blank screen where grub should be, no error messages, just hangs. ... The main point of this message is to make people aware of the problem and suggest admins don't run 'yum update' until they understand the problem and have a fix at hand. I posted, on 7/30, to CentOS-devel the following after my similar experience (booting an mSATA SSD on my M6700, with two 2.5 SATA drives (a 1TB and a 2TB), and the mSATA is not /dev/sda on this hardware, FWIW): "Moral of the story? Have the install DVD on a USB stick and available to boot into rescue mode, know how to boot rescue mode (from the installer boot menu select 'troubleshooting' then 'rescue' and option 1 once the menu shows), know how to activate network interfaces in text mode (either nmcli or nmtui works fine for this), and know a few basic dnf commands. And have an alternate means of doing basic web searches available; my android phone this morning was used for that." I was able to recover with the install DVD on a USB stick and using rescue mode on a laptop with only WiFi (nmtui does a great job for this sort of thing, booted into rescue mode and chrooted onto /mnt/sysimage). ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] 8.2.2004 Latest yum update renders machine unbootable
On 8/1/20 5:54 AM, Alessandro Baggi wrote: You said that in the centos infrastructure only one server got the problem. What are the conditions that permit the breakage? There is a particular configuration (hw/sw) case that match always the problem or it is random? I experienced the issue on a Dell Precision M6700 (UEFI, Core i7-3740QM) on the first attempt at update; I recovered by rolling back and reinstalling grub2-*; I then updated on the command line with dnf update and now that same hardware that crashed out the first time is working fine with the same package versions. It seems to be intermittent, and I can't reproduce it. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] 8.2.2004 Latest yum update renders machine unbootable
On 8/1/20 5:00 AM, Johnny Hughes wrote: I would wait and install everything as a group. We should have something soon. First off, Johnny and all of the rest of the CentOS team, thank you for your efforts! Second, to all with this problem, I too experienced the issue (I posted on the CentOS-Devel list my findings). To those who seem to think more testing could have prevented the issue, let me just say that while the FIRST update to the new shim-x64, grub2, and kernel stack failed for me (and that update was done with the GUI updater that reboots for the actual update), I WAS able to recover using the install media's rescue mode tools as documented in my posts on CentOS-devel. I'm glad to provide any and all logs of the processes I did, but the short of it is that after I successfully downgraded grub2 it still wouldn't boot, but I was able to do a reinstall of grub2 (81, the older version) to get it to boot with the old grub2, the new shim-x64, and the new kernel, and then I was able to successfully update grub2 with dnf on a command line. So I have the following installed: [lowen@localhost ~]$ rpm -q shim-x64 shim-x64-15-13.el8.x86_64 [lowen@localhost ~]$ rpm -qa | grep ^grub2 grub2-common-2.02-87.el8_2.noarch grub2-tools-2.02-87.el8_2.x86_64 grub2-efi-x64-2.02-87.el8_2.x86_64 grub2-tools-extra-2.02-87.el8_2.x86_64 grub2-pc-2.02-87.el8_2.x86_64 grub2-tools-efi-2.02-87.el8_2.x86_64 grub2-tools-minimal-2.02-87.el8_2.x86_64 grub2-pc-modules-2.02-87.el8_2.noarch grub2-efi-x64-modules-2.02-87.el8_2.noarch [lowen@localhost ~]$ rpm -qa | grep ^kernel|grep 147 kernel-devel-4.18.0-147.8.1.el8_1.x86_64 kernel-4.18.0-147.8.1.el8_1.x86_64 kernel-modules-4.18.0-147.8.1.el8_1.x86_64 kernel-core-4.18.0-147.8.1.el8_1.x86_64 [lowen@localhost ~]$ And this is on a machine that previously crashed during boot with the exactly the same packages. So even on the same hardware the same update (done a bit differently) had different results. It's quite possible, based on my experience with this particular issue, that if I had the whole system rolled back to where it was before the GUI update and if I then updated it again that it could just simply work ok afterwards. It's very hard to test for intermittent issues! ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] C8 - KVM on bridge on VLAN on team issues.
On 6/18/20 1:35 PM, Lamar Owen wrote: So, I set up another development host, but this time using a team instead of a bond, and I'm going to try to get that working with bridged networking to a virtual guest, since it really is supposed to work, and I'm very curious why it didn't. So, finally got back around to this. So, on this host I had set up a team0 with a bridge192 and with the bridge192 having an IP address, etc. That all worked fine. However, after creating a guest on this host, the guest had no connectivity through the same bridge. So, I thought I might see what setting the hairpin option might do, on the port of the bridge connected to the team. Well, lo and behold, after setting this up in the cockpit web interface, and after the networking restart initiated by cockpit, now I have connectivity to the guest. HOWEVER, the bridge port is NOT showing hairpin as configured. Could it have been the connection restart that connected the bridge port up correctly, since the guest was running which the connection restart occurred? Whatever; it is now passing traffic with no other configuration changes. Now to see if I can duplicate this on a reboot later this week; that server is busy running some other things right now. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] what's the advantage of NetworkManager for server?
On 6/29/20 11:20 AM, Gordon Messmer wrote: ... In the event of a power loss, many servers will boot faster than the managed Ethernet switch they are attached to. Systems managed by network-scripts may not set up their network because there is no carrier at the time that networks-scripts start up. Network-manager, on the other hand, will set up networking whenever the interface becomes ready. At $dayjob we got to see the advantages of this up close and personal a few days ago when we had a hard failure in the voltage regulator/exciter loop of one of our three primary generators during a utility power failure. First failure of this kind since that datacenter was placed online in 2008, and only the second power out event since 2008. (While critical systems have dual generator backup, and all systems have UPS with a few minutes run time, the systems affected by this weren't previously classed as 'critical' enough to have dual feeds, although that might change in the next few weeks). So, we have a virtualization host in an IBM Bladecenter with iSCSI shared storage on some EMC Clariion LUNs through a Cisco 7609 switch/router with RSP720. Anyone who has ever dealt with these items in a cold boot situation probably knows how the litany goes at this point. Prior to the NetworkManager intelligence, I would have to manually reset the host in the Bladecenter after the EMC was up and after the 7609 was up. Not any more. Nice. (Clariion can take 15-20 minutes to come all the way back up on a hard power fail; 7609 can take 10 minutes if not longer. Bladecenter takes 5 at most.) ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Blog article about the state of CentOS
On 6/24/20 12:27 PM, Lamar Owen wrote:
... You can look in the %{BUILDTIME} query tag for build order; use
the following command to get the order:
rpm -qa --queryformat "%{BUILDTIME} %{NAME} %{EPOCH} %{VERSION}
%{RELEASE}\n" | sort
So, replying to my own post here, as build order is only part of the
story. Determining the contents of what was in the actual BUILDROOT at
%{BUILDTIME} can be right difficult, since the BUILDROOT is not
guaranteed to have every package that has a prior %{BUILDTIME} in it.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Blog article about the state of CentOS
On 6/20/20 6:50 AM, Peter wrote:
On 20/06/20 3:50 am, Johnny Hughes wrote:
And EL8 is exponentially harder with an entirely new build system and
the requirement to build modules.
But it seems like every major release has had reasons to be
exponentially harder than the last. With 7 it was the shift to using
the git sources instead of the SRPMS that were previously provided by
Red Hat, thereby necessitating an entirely new build system, plus the
change to systemd and the introduction of a new point release
numbering scheme, not to mention the move to entirely new
infrastructure because of the change to Red Hat sponsorship.
Using git to build sources from, while a change, doesn't significantly
increase the number of packages that need building. The actual package
building - compilation - stage can take days on even the fastest
hardware. Yes, the build infrastructure is different, and yes there is
a learning curve involved, but I have found that the mechanics of
building the source is not really that different from doing it with
source RPMs. Instead of 'wget src.rpm; rpmbuild --rebuild src.rpm' you
do a 'git clone $rpm-package; git checkout $tag; get_sources.sh;
rpmbuild -ba $tree' for a full manual build; I've now done this a few
times, and it's not really difficult, just a few more keys to press.
What can't now be used is the %{BUILDTIME} embedded in the source RPM
that can give you clues as to build order; a git commit of a thousand
packages can be atomic and all at the same time.
The use of systemd has nothing at all to do with the build difficulty;
it's just another package for that purpose; likewise, the new release
numbering has nothing to do with build and QA difficulty.
...
It would appear that the package build was completed on the 4th of
May, why didn't we get a CR repo dump this time around so that CentOS
users wouldn't have to wait another month before getting critical
updates?
CentOS users who can't wait for CentOS to release 'critical' updates
really should reconsider using something else; that might be RHEL, that
might be something completely different. This is part of the calculated
risk of using CentOS, and this hasn't changed since 2.1. That's not
going to change, nor can it thanks to all the reasons Johnny mentioned.
Building a full distribution from sources can be a hard problem.
As far as the first build iteration completion date is concerned, that
should be considered a rough draft build; if the QA process finds binary
incompatibility (library linkage versions for the most part) then
several if not all packages need rebuilding as part of the QA stage. Do
you REALLY want to use first-draft stage 1 packages in production? You
can look in the %{BUILDTIME} query tag for build order; use the
following command to get the order:
rpm -qa --queryformat "%{BUILDTIME} %{NAME} %{EPOCH} %{VERSION}
%{RELEASE}\n" | sort
Or you can go through the released packages on centos.org and look at
the build dates to see how many packages were built pretty late; for
instance, bpftool-4.18.0-193.el8.x86_64.rpm apparently wasn't built in
the released version until 2020-05-29. I'm reasonably sure the first
pass at this was built probably a month earlier based on the dates of
other packages, but something was probably found in QA that required a
rebuild, or the rebuild depended on something else that was late to build.
AND since this rebuilt package HAS TO KEEP THE SAME
Name/Epoch/Version/Release (NEVR) tuple to be RHEL-compatible, the first
N=bpftool V=4.18.0 R= 193.el8 could not be released; who knows, there
may have been a dozen of the same NVR (bpftool's %{EPOCH} is (none) and
so I don't count it)... If the first N=bpftool V=4.18.0 R= 193.el8
were to be released, then how, within the RPM update decision mechanism
that only uses the EVR to update, is dnf/yum/rpm going to know the
version built on 2020-05-29 is updating the one built on say
2020-04-26? No, ${BUILDTIME} is NOT used for update decisions, sorry,
and bumping %{EPOCH} is the nuclear sledgehammer of RPM versioning and
thus is strongly discouraged. For complete compatibility you want every
package to have the same NEVR in CentOS as in RHEL except where
CentOS-specific changes had to be made (branding, mostly).
And then there's modularity in CentOS 8, which means packages might have
to build against a whole 'nother set of packages (I'm thinking
specifically of the three different PostgreSQL versions that are
modularized, or the mariadb versus MySQL modules with their libraries,
and so on) that does indeed dramatically increase the number of package
builds that not only need building but then need QA testing. Or do you
want to run untested packages in production to get the packages sooner?
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] C8 - KVM on bridge on VLAN on team issues.
On 6/17/20 4:07 PM, Lamar Owen wrote: On 6/17/20 1:51 PM, Ulf Volmer wrote: ... Just to make it sure: Did you try to disable firewalld? With my experience with libvirt and vlan bridges on Fedora, libvirt may include unwanted firewall rules which drops the traffic over the bridges. I haven't done that yet, so I'll try that next. Thanks for the idea. So, I tried dropping the firewall, etc. No joy. So I punted; I did a scratch reinstall of C8.2.2004 on the host, using the 'Virtualization Host' group, and creating one bridge on the management VLAN, but this time on top of a bond, not a team. After install, reboot, and updating to latest, which verified that the management IP and VLAN has connectivity, I then used nmtui to create the second bridge on the second VLAN on top of the bond. I then connected to libvirt with virt-manager on my laptop, and installed a minimal install of C8 as a guest, connected to bridge302 again, with a static address. After the install and reboot, I checked with a ping on the guest to its gateway; hooray now it works. I was able to update the guest and get the application server installed that is goig on the guest, with good throughput. Other than this one using a bond instead of a team I don't see any difference in the bridge setup. No extra work was required to get it to work, either. So, I set up another development host, but this time using a team instead of a bond, and I'm going to try to get that working with bridged networking to a virtual guest, since it really is supposed to work, and I'm very curious why it didn't. But the first guest running that particular application server is required in pretty short order, too short for me to play around trying to get teaming to work properly for a bridged-on-a-VLAN guest. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] C8 - KVM on bridge on VLAN on team issues.
On 6/17/20 1:51 PM, Ulf Volmer wrote: ... Just to make it sure: Did you try to disable firewalld? With my experience with libvirt and vlan bridges on Fedora, libvirt may include unwanted firewall rules which drops the traffic over the bridges. I haven't done that yet, so I'll try that next. Thanks for the idea. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Blog article about the state of CentOS
On 6/17/20 3:32 PM, Phil Perry wrote: On my home file server for example, which is not connected to the internet, what does it matter if the release is 1 month or 3 months out of date? I can install the server in the knowledge it's going to work, and be supported with updates for 10 years and I can largely forget about it. My el5 box ran for more than 10 years until the hardware eventually died. EL5... how modern... from a production application server VM, not internet-connected: [root@c6-2850 ~]# ssh root@10.1.x.y root@10.1.x.y's password: Last login: Tue Jan 28 19:53:32 2020 unknown terminal "xterm-256color" unknown terminal "xterm-256color" [root@localhost root]# cat /etc/centos-release CentOS Linux Advanced Server release 2.1AS (Slurm) [root@localhost root]# This one has to be hard reset every day or two (virsh reset rhel2.1) since the bridge to the guest just dies randomly, and a reboot inside the guest hangs hard before finishing the reboot. The hard reset has to manually load the ethernet kernel module after it's booted up so far; if the ethernet module loads too soon it will never connect haven't found the reason for that, either, just run a pinging script every fifteen minutes on the host to check for connectivity and 'virsh reset rhel2.1' when it fails. The appserver is hard reboot resilient, and the software does a very specific task, and there's no budget for a rewrite. At least I did upgrade it from Red Hat Linux 5.2 a couple of years ago (the RHL5.2 box, an old AMD K6/2-450 with 128MB of RAM, ran almost continuously for 20 years). Thanks, CentOS! ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Blog article about the state of CentOS
On 6/17/20 10:19 AM, Leon Fauster via CentOS wrote: ... I wonder about the authors conclusion; the fact that RHEL is the choice for critical applications (what ever critical is) is known since the early days. This applies randomly to C5.11, C4.9 or C8.2.2004. So - cold soup get cooked again :-) Indeed. The author's conclusion has been the case since White Box Enterprise Linux was a thing. Anyone and everyone can get the sources from git.centos.org as soon as they are released and build the stuff themselves if they think it can be done faster; that's how WBEL got started, as a one-user project that just happened to be publicly released. Building from source has never really been any easier; the lack of .src.rpms is not an impediment to just getting something built. But the CentOS value-add is that those rebuilt sources have been tested for binary compatibility and are from a trusted source. A one-person project like WBEL would have a much more difficult time today, with modularity especially. Build times for these packages is not zero. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] C8 - KVM on bridge on VLAN on team issues.
On 6/17/20 11:04 AM, Lamar Owen wrote: ... It shows as being defined to 1. I'm going to try adding to sysctl.conf and see if that makes any difference, though. No difference. What is aggravating, though, is virtually every howto on bridging out there refers to the deprecated brctl utility (from the bridge-utils package), and C8 no longer includes that package (even though it's in current Fedora 32!). I know, I know, the new way is using the 'bridge' command or 'ip --br' So I grabbed the F32 source RPM and rebuilt on my C8 laptop and uploaded to the host: [root@c8-kvm-pe1950-1 ~]# brctl show bridge name bridge id STP enabled interfaces bridge101 8000.001ec9fcde9d yes team0.101 vnet0 bridge302 8000.001ec9fcde9d yes team0.302 bridge68 8000.001ec9fcde9d yes team0.68 Still no dice. Next step is tcpdump. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] C8 - KVM on bridge on VLAN on team issues.
On 6/17/20 9:59 AM, Deventer-2, M.S.J. van wrote: Hi, the first thing that comes to mind, did you set ip_forward to enable in /etc/sysctl.conf ? net.ipv4.ip_forward = 1 Should explain why you IP on the bridge works but not on the vms. First, thanks for the reply and excellent suggestion. Yeah, I thought about that, and while it's not specifically defined in /etc/sysctl.conf or /etc/sysctl.d/*, if I: [root@c8-kvm-pe1950-1 ~]# cat /proc/sys/net/ipv4/ip_forward 1 It shows as being defined to 1. I'm going to try adding to sysctl.conf and see if that makes any difference, though. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] C8 - KVM on bridge on VLAN on team issues.
As part of my initial KVM host on C8 deployment, I decided to set up some HA features on the new host, specifically NIC teaming. Teaming seems to be bond++ of a sort, so I thought I would at least try it. So here's the scenario: 1.) Server with two gigabit ethernet ports, two Cisco switches. 2.) During install, used the 'Server with GUI' group and added the virtualization packages. 3.) During install, set up team0 to include the two gig-e ports set up active-backup (two switches). 4.) During install, set up three bridges, with the slave devices being VLANs pointed to the team0 subinterfaces (using VLANs 68, 101, and 302; 101 is to be the management bridge for the host, with guests on all three VLANs). So, for instance, bridge101 has a slave that is VLAN101 that points to team0.101 with a VLAN ID of 101. The bridge101 interface has a manual IP address, but bridge68 and bridge302 do not (IPv4 disabled; IPv6 Ignore) 5.) After reboot, the bridge101 interface comes up, and I successfully connect to the host, since the install is 8.1.1911, I ran a 'dnf update' up to 8.2.2004, which went well, then I successfully set up and used cockpit, cockpit-bridge, cockpit-machines, again over the IP address on bridge101. Ok, now that the base connectivity is working: 1.) Connect to the host (traffic on bridge101 over team0.101) using virt-manager on my laptop and install a C8 guest, with the network pointed to bridge302, and a manual IP address. 2.) After reboot of guest, there is no IP connectivity to the guest's gateway on VLAN302. 3.) HOWEVER, the gateway's MAC address shows up in the host's bridge fdb for VLAN302, AND in the arp output for the guest; ALSO, the MAC address for the guest shows on the cisco switch 'show mac-address-table' output. The output of 'ip --br link' looks normal for this configuration, but there's a disconnect somewhere. So, since I see that VLAN101 is passing traffic to the bridge correctly (since the management IP is on that VLAN), I try to set up a guest on VLAN101; no dice, no work, but the management IP still works fine. So, does anyone here have a working setup with KVM guests connecting to bridges using 802.1q VLANs on top of a team? Or even on top of a bond (I can reinstall and set it up as a bond easily enough, using active-backup, as far as I know; and, yes, I would reinstall the host from scratch to do this). ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] virt-manager guest and sound
On 6/10/20 10:57 AM, Jerry Geis wrote: I am running C7 host and pulse audio. I have a Win 10 guest with ICH9 audio. It works - but I hear artifacts. Anything to do to help audio be flawless under guest VM ? I've experienced this as well, and haven't really dug into it, since my main pro audio production tools (Harrison Mixbus and Mixbus32C) are Linux-native. I do have Celemony Melodyne on Windows, but I haven't used it heavily enough in virtualization to notice. I may take a look at it soon, if I need Melodyne badly enough in the near future, but since upgrading to CentOS 8 this week I have plenty of other things to keep me busy. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] In CentOS 8 new install, old /home, .desktop opens in gedit
Ok, hoping someone has seen this or at least knows where to look. I have been waiting around a bit to upgrade my system to CentOS 8, and actually wanted to wait on 8.2, but had an opportunity this week to actually do the work, so took the opportunity. Here was my process: 1.) Installed CentOS 8.1.1911 on a spare mSATA SSD in my spare M6700 laptop. Installed the RPMfusion nVidia drivers, the PowerTools repo, set up the extensions for Places, Applications, etc, and got it prepped to accept my /home disk. 2.) After complete backups, physically moved my /home disk from the CentOS 7 M6700 to the CentOS 8 M6700. /home is on a LUKS LVM lv; got all the mount options and encryption options setup to start on boot. All of that now works, even though it took a bit of wrangling (if the filesystem mount is set to start up at boot without the nofail option BUT the encryption option is left at the User Default setting, it will not work!). Did a complete SELinux relabel (touch /.autorelabel and reboot). Moved the default GNOME config dirs over to the old /home; don't want a lot of cruft left over from the C7 install (which has been upgraded over the years from C6, Fedora 14, and earlier, and it was time to get rid of some cruft, I'm sure). After booting back up with the old /home in place, verified the GNOME extensions settings I had set up after the new install. All looks good, and working like it's supposed to so far. 3.) Moved over the Win10 and Win7 virtual machines, all of that works fine. 4.) Started installing my everyday programs, beginning with Harrison Mixbus. The program put its menu entry in place; all good. However, when I go to double click on the .desktop shortcut, it opens in gedit. Hmm, this ain't quite right. This worked fine on C7 in GNOME Standard mode. So, at this point, the Mixbus_6.0.702.desktop file is on my desktop, it's in ~/Desktop with executable permissions and is owned by the correct user, but right-clicking on it does not bring up the choice to 'Allow Launching.' The GNOME Extension 'Desktop Icons' is installed and is active. I've tried a whole lot of suggestions, but wanted to see if anyone here had seen this before and has solved the problem to allow launching of the .desktop file as it is supposed to do. Just knowing that 'it works for you' actually is helpful, especially if we can figure out what is different from my install to yours (SELinux context, permissions, etc). Just knowing where to look would be helpful; and I'm going to diff my old GNOME config from my /home backup to the fresh as-installed config gnome-shell-extension-desktop-icons-3.32.1-10.el8.noarch is installed. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [CentOS-announce] Release for CentOS Linux 8 (1911)
On 1/16/20 2:07 PM, Warren Young wrote: On Jan 16, 2020, at 12:06 PM, Lamar Owen wrote: ...or maybe even 8.1.1911 (which is part of the name of the DVD ISO file), but officially it's CentOS 8 (1911). $ lsb_release -a LSB Version: :core-4.1-amd64:core-4.1-noarch Distributor ID: CentOS Description: CentOS Linux release 8.1.1911 (Core) Release: 8.1.1911 Codename: Core Sure; I said 'officially' not 'technically' and 'technically' it's 8.1.1911. That was part of the hashing back in the early days of C7. /etc/centos-release also contains the 'technical' release number. (I had assumed my reply would have been more obviously tongue-in-cheek to anyone who's been around CentOS for any length of time.. :-) sorry I didn't make it clearer) ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [CentOS-announce] Release for CentOS Linux 8 (1911)
On 1/16/20 6:49 AM, Peter wrote: On 16/01/20 4:14 am, Brian Stinson wrote: Release for CentOS Linux 8 (1911) We are pleased to announce the general availability of CentOS Linux 8. CentOS 8 was released in September 2019. Don't you mean 8.1? No, they mean CentOS 8 (1911). This was hashed to death back in early CentOS 7 days, so shouldn't need rehashing again.. Yeah, I know most people are going to call it 8.1, or maybe even 8.1.1911 (which is part of the name of the DVD ISO file), but officially it's CentOS 8 (1911). ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] copying files to fill flash drives
On 1/10/20 2:33 AM, Frank Cox wrote: Back in the days of DOS I had a program that I obtained from somewhere called FILL. ... Before I re-invent the wheel here, does someone already have a way to do this with Linux so you can write a series of flash drives and fill them with the contents of a specified directory without modifying the files that get written? This would, in my opinion, be a useful thing. I found several simple knapsack implementations; one of which is at https://github.com/vaeth/knapsack What would be very useful is to dynamically load the knapsack based on size of whatever USB drive you just plugged in; so if you have say 4 32GB drives, a 128GB drive, and a 64GB drive, the filling would be efficient no matter which order you plug the drives in. There have been several times I have wished for such a utility; I had one for the old TRS-80 LS-DOS 6 when I ran a TRS-80 Model 4 with a 20MB hard drive to copy to floppies, even when the floppies might have a different amount of free space. I've done the multi-floppy tar thing back in Xenix days, and that was painful to say the least. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] State of CentOS 8
On 12/23/19 3:16 AM, Nicolas Kovacs wrote: Le 23/12/2019 à 02:48, Akemi Yagi a écrit : You may want to watch the "CR work" on that wiki page. CR seems to be empty right now. Not any more; updating one of my testing C8 VMs to the CR content now. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] C8: Wayland Session / Cut and Paste
On 11/7/19 3:13 PM, Leon Fauster via CentOS wrote: Is this the normal behavior now? Cutting text in gedit and pasting it into the terminal needs that the source application stays running? I've run into this behavior for a while, for several CentOS versions, depending upon the application. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Odd issue with 7.7.1908 updated with qemu-kvm-ev
On 10/15/19 10:28 AM, Simon Matter via CentOS wrote: Hi, ... After the update on the host to 7.7.1908, the network stopped running. The host also has a CentOS 7 guest that is still working properly. If I change the 2.1 system to not automatically load the e1000 driver and console in and 'modprobe e1000' manually, it starts working again, for a while. Just as a workaround, did you try to use another network card than the e1000? Yes, I did; the only other option was for the 8139 NIC, which in CentOS 2.1 is the '8139too' driver. And it worked; until I rebooted the guest and the driver was loaded automatically. If either driver is loaded manually, after the 'ifup eth0' has already been executed, it works, at least for a few hours. There are no virtio drivers that I could find for C2.1 (not surprising). I did forget to mention that this is bridged networking, and is working great for the C7 guest that is on the same C7 host. Even when the C2.1 guest's connectivity goes down, the bridge shows as up and not blocking. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Odd issue with 7.7.1908 updated with qemu-kvm-ev
So, I have a client that has an internal use application that needs an ancient version of libc5. That's not a typo; libc5. Before the server that ran it died about a year and a half ago (said server was an AMD K6-2/450 with a 6GB Western Digital Caviar drive that had been spinning nearly continuously for almost 20 years!) it was running on Red Hat Linux 5.2. The last version of CentOS that shipped with a libc5 was 2.1. So I set them up a KVM guest running CentOS 2.1, mainly because Red Hat 5.2 wouldn't recognize the network at all, using the e1000 network driver, and it ran well. Now, yes, there are no updates, but no it doesn't matter; it's an internal use application that has a very small footprint and very low risk. After the update on the host to 7.7.1908, the network stopped running. The host also has a CentOS 7 guest that is still working properly. If I change the 2.1 system to not automatically load the e1000 driver and console in and 'modprobe e1000' manually, it starts working again, for a while. Any ideas as to where to start looking? qemu-kvm-ev itself, or libvirt? I'm planning to start out with rollbacks to the previous versions of each to try to find where the issue starts. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Gstreamer1
On 10/14/19 9:06 PM, Jerry Geis wrote:
How do I tell from source rpm's:
1) the build order of gstreamer packages
I replied from my phone yesterday, and it doesn't appear to have gone
through...
The _chronological_ build order is most easily inferred from the RPM tag
%{BUILDTIME}. Usage example:
+++
[lowen@dhcp-pool102 ~]$ rpm -qa --qf "%{BUILDTIME} -- %{NAME}\n" |grep
gstreamer1|sort
1501713160 -- gstreamer1
1501713160 -- gstreamer1-devel
1502039500 -- gstreamer1-plugins-good
1523411572 -- gstreamer1-plugins-bad-free
1523411572 -- gstreamer1-plugins-bad-free-gtk
1523411627 -- gstreamer1-plugins-ugly-free
1540923990 -- gstreamer1-plugins-base
1540923990 -- gstreamer1-plugins-base-devel
[lowen@dhcp-pool102 ~]$
+
It's pretty easy to see which packages were built at the same time, and
the chronological order the others were built in. To query this from a
set of src.rpms just use 'rpm -qp ' with the full package
filename(s) instead of just the package name. I used -qa and a grep
feeding a sort to keep it 'simple,' although I have mixed repositories
represented in that build order. With a set of src.rpms you have better
control of what you're checking in terms of the order of the build.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 8 network-scripts
On 10/5/19 2:14 PM, Always Learning wrote: Technically [the new automobile] was never an "upgrade" but a brand new and alternative system. ... The automobile was originally billed in many areas as the 'horseless carriage,' an upgrade. Luxury. Try running on a 32k single processor computer, started with booting the card reader which read cards that booted from a tape. ... Frontpanel, 256 words (12-bit words), and paper tape. But I also never had that straight-8 on the net, either, but, via uucp, I did have the T6K on Usenet. No comparison between 50+ years ago with this constantly developing and fascinating New World. However KISS remains valid. If it works smoothly, don't mess it up. But that's the point; the previous solution didn't work as smoothly for all use cases as one might want to believe. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 8 network-scripts
On 10/5/19 11:29 AM, Stephen John Smoogen wrote: ... On the other hand, most of the idea that the old config scripts were deterministic and imperative was built on a large amount of hacks to try and make it so. Having spent more time than I want dealing with systems which seem to be just like everything else but coming up with eth0 being eth4 (I am looking at you 40 Dell, HP and IBM boxes) on a reboot half the time.. ... I remember having that happen a few times back in CentOS 4.x days, where eth0 would silently become eth1 after a kernel update and ifcfg-eth0 would break hard. It's gotten a lot better than it was, and I've had very few problems in my use cases with NM. YMMV, of course. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 8 network-scripts
On 10/4/19 11:39 AM, Ljubomir Ljubojevic wrote: ... I have VM in NAT mode mostly these days, but sometimes I need bridged network to recognize some hardware on the network, Mikrotik WiFi routers or printers so I need ability to go to bridge. I've kludged together a solution for those times here by using the NAT connection, but then running an OpenVPN client on the guest to an OpenVPN server with layer-2 adjacency to those sorts of devices. That has the added bonus of letting those layer-2 services work even from off-site (part of the reason I use LUKS!). I use static addresses in the OpenVPN setup as well, allowing controlled access to certain resources (like the control interface addresses and ports to our two 26-meter radio telescopes). If this with NetworkManager-config-server package works, I can at most times (if I want) plug a LAN to my laptop and be happy. I am interested in what you find! I have Dell Vostro 15 with Core i7, 12GB RAM and 512GB SSD + 1TB HDD Dell Precision M6700 with Core i7-3740QM @ 2.7GHz, 24GB RAM, 500GB SSD plus 2x 1TB HGST 7K1000's. I never buy new, always gently preowned, and it's amazing to me how well the 3740QM performs relative to newer stuff and I paid less than 10% of MSRP for it ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 8 network-scripts
On 10/4/19 11:02 AM, Ljubomir Ljubojevic wrote: ... It is OK if your KVM host is on LAN cable that never is disconnected or power goes down. But I have a laptop I use first at work where I use LAN and then at home where I use WLAN only, and suspending laptop is same as disconnecting LAN, bridge is disabled and KVM bridged network unhooked, and you can never reinitialize it without at least restarting kvm, and full treatmant is shuting down VM, restarting NM then network then starting VM again... So I just shutdown VM and laptop and boot everey itme I move. Maybe I can change this behavior now. You and I have nearly identical use cases, interestingly enough. My laptop that I'm using right now to type this is my development machine for a number of KVM things I do in the data center as well. Since I run it docked with ethernet on my desk, but not docked and on WiFi at home, I've had to do two things: 1.) A real shutdown when I leave work. For some reason I've never be a fan of suspend/hibernate, and since I use LUKS I'd rather not leave the volume unlocked as it would be in a suspend/hibernate scenario; 2.) NAT-connected VMs in development, since I've never been able to get bridging to work properly over wireless (specification says it can't work, and I think that's true in practice, but I always reserve the right to be wrong!). My laptop is at least as powerful as most of our servers, and it works great for development purposes. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 8 network-scripts
On 10/4/19 10:40 AM, Valeri Galtsev wrote: My impression is younger generation doesn't value rules that programmers were following 2-3 decades ago. One of which is: Do not make any changes [in the program] unless they are absolutely necessary. I have in the past agreed with this assessment more than once. And I _am_ somewhat of an old hand at this, having run Unix and Unix-like systems for a bit over 30 years. The fact of the matter is that, even though some of the old ways work just fine and don't need to be changed, many more times I've seen that, if the old way was a kludge to begin with, maybe there really is a better way to do it. Take the transition from horse and buggy to automobile for instance. Iron rim tires work just great for the buggy, not so great for the automobile; a change had to be made in an old technology (the wheel) to meet the needs of the new automobile. Lots of wheelwrights probably fought that change, too. I've seen the old ways, and there are more kludges out there than some would like to admit. (obOldWayRef: article on 'the kluge' from the 1966 Datamation book 'Faith, Hope, and Parity.') Just remember: the old ways back then was punch card and batch; what do you mean you want more than one person to use such an expensive thing as a computer live, wasting its valuable time? Many seem to forget just how subversive Unix was back in the day relative the the old ways. ... Yet one more thing is: building superstructure on top of what actually works. The definition of what works can and does change over time. Sure, an iron rim wheel can work for the new automobile, but the basic change in what the wheel needed to do (with buggy the wheel doesn't need to provide good traction, that's what hooves are for, and narrow and smooth work best; with the automobile all of a sudden the drive wheels need to provide traction, and even though the iron-rim wheel still works after a fashion on smooth ground, there is a better way to do it). I can just hear the old-school wheelwrights saying "well, if it gets stuck in the mud then just don't go in the mud!" or "why would anyone want to go faster than the horse-drawn buggy could?" or "why would you need to turn that quickly and at that speed?" or "why in the world would you want brakes to stop you that quickly?" and the list goes on. I _am_ old-school in thought, but I do consciously make the effort to understand the newer reasoning, rather than be the greybeard that constantly talks about how I did it in the old days. Heh, in the old days I made it work with K C, 1MB of RAM, and an 8MHz CPU and I griped about the misfeatures then!. Today, I'm doing things with containers, virtualization, dynamic load balancing, software-defined infrastructure/IaaS, etc that the old ways simply cannot handle. NetworkManager/systemd/etc in CentOS are far from perfect, but at least they're trying to solve the newer problems that the old ways in many cases simply cannot. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 8 network-scripts
On 10/4/19 10:00 AM, Ljubomir Ljubojevic wrote: On 10/4/19 3:03 PM, Chris Adams wrote: ... See the NetworkManager-config-server package. Ahh, thanks. I was wondering about it but never investigated. H. Description : This adds a NetworkManager configuration file to make it behave more like the old "network" service. In particular, it stops NetworkManager from automatically running DHCP on unconfigured ethernet devices, and allows connections with static IP addresses to be brought up even on ethernet devices with no carrier. This package is intended to be installed by default for server deployments. ++ Well, learn something new every day nice. Time to learn a bit more about what it will do, and see about deploying to our KVM hosts. I've not had the bridged network issues some seem to have been plagued with, and I have several KVM hosts with bridged networking (with multiple VLANs) using NetworkManager (using nmtui to configure a bridge isn't hard). I decided to configure it that way just ot see how easy or hard it was to do with NM, and to test its stability, and after passing testing under load I popped it into production, running a few Windows 7 guests and a couple of CentOS 7 guests. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] kpatch (live kernel patching) in CentOS 7.7?
On 10/4/19 9:35 AM, Phelps, Matthew wrote: ... I'm still puzzled why RedHat is doing it then, and making it more generally available (to paying customers even), if it's so dire a proposition that it will fail so badly, so often. That seems counter-intuitive to me. It would likely boil down to a risk-benefit analysis; for RHEL RH is willing to take the risks associated with it due to the added benefits of offering it. And, well, the elephant in the room is that it is one of the things that make an RHEL subscription more attractive, whether that's an intended effect or not. Ubuntu/Canonical apparently made a different analysis, per another poster in-thread. Of course, I'm in a similar situation to you in that we're a non-profit and don't have the budget for RHEL subscriptions. So what I've done here is to stay on top of what the kernel issues are, and schedule reboots accordingly, and take those long-running analysis job machines and temporarily suspend general Internet accessibility until a reboot is possible if the kernel issue warrants that. I likely don't have anywhere near as many of those jobs running as you, but I still can sympathize! Anyway, I again point out that the CentOS documentation should be made clear that this functionality won't ever be coming to CentOS. I would suggest the team, rather than a blanket statement that it's 'never' coming to CentOS would articulate (Smooge's posts are a great start!) what it would take from the community to make it happen, thus leaving the question open-ended. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] C8 install libreoffice
On 9/27/19 6:07 PM, Jerry Geis wrote: How do you install libreoffice. yum install libreoffice did not do it, doing a search on "centos 8 install libreoffice" did not provide anything. Thanks Well, libreoffice packages ARE in AppStream, and a 'yum list|grep ^libreoffice shows a bunch, but there's no blanket 'libreoffice' package, you'll need to install each component. This can be done from the command line or using the 'Software' GUI. I tried the 'yum module list' route, and there isn't a module for libreoffice, so installing each one seems to be the way at least for 8.0. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Opinions on using CR repository in production environments.
On 9/12/19 3:10 PM, Gwaland wrote: ... So would you treat it as a production repository or for testing only? Do we know how it's actually intended to be treated? Well, like virtually everything else, It Depends (TM). The first depends, for me, is how critical are the fixes relative to what I need in production? So, what I do, is keep a test server running on the same hardware as my production servers, and update to CR on it first, making sure it reboots ok, since I have had the reboot not be ok on a new 7.x release (the UEFI vars memory overflow due to shim rebased to v15; see https://bugs.centos.org/view.php?id=15522 ). Once I see it reboots ok, I test. Since my own laptop is running CentOS 7 as well, I'll update it to CR for testing; nothing like living it for your daily main computer to tune you in to issues! Once I'm satisfied CR is stable, then, if and only if the first depends is met, I'll update affected servers to CR, if the fixed issues are critical enough. If they're not that critical, then I hold off until GA. The second depends is whether there are other dependent packages I need that aren't yet updated. If so, then I wait until those packages are ready, then update. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Mail server with both postfix and sendmail installed, active MTA gets switched.
On 1/5/19 2:18 AM, Gordon Messmer wrote: On 1/4/19 8:29 PM, Lamar Owen wrote: I have had updates twice now switch the active MTA to sendmail, and I have to manually 'systemctl disable sendmail; systemctl stop sendmail' and 'systemctl enable postfix;systemctl start postfix' afterwards. Run "systemctl mask sendmail" as well. That should permanently disable the service. Worthwhile thing to do; still curious about what caused it, but if this will lock it out. I am trying to find out what package update caused this to switch; or which logfile to look at to show me the systemctl messages that show the enable/disable sequence and points me to the correct package to file the bug against. ... If the problem is a trigger on the sendmail package, it could run without any changes to the sendmail package itself. Ah, yes, indeed. Only three packages are output: sendmail itself, postfix, and the third party software; postfix did get an update recently, and after checking to see I didn't reboot after that update. And the postfix scriptlets do twiddle with alternatives, using the --initscripts command to alternatives; and this is what I believe did me in. So, it seems as part of my setup that I failed to set the alternatives properly, and that has been corrected, as well as setting 'systemctl mask sendmail' so we'll see how that rides... Thanks, Gordon! ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Mail server with both postfix and sendmail installed, active MTA gets switched.
Ok, so a bit of a long subject line there... I'm running an email server using postfix, but a critical third-party package being used requires 'sendmail' the package. No, I can't uninstall that package, please don't suggest that, and I don't have control of its requires. So both postfix and sendmail are installed, and that's just the way it has to be. Amavisd-new and clamav/clamd, from EPEL are also installed. I have had updates twice now switch the active MTA to sendmail, and I have to manually 'systemctl disable sendmail; systemctl stop sendmail' and 'systemctl enable postfix;systemctl start postfix' afterwards. I am trying to find out what package update caused this to switch; or which logfile to look at to show me the systemctl messages that show the enable/disable sequence and points me to the correct package to file the bug against. The packages updated today when this happened were: # cat /var/log/yum.log Jan 04 16:42:47 Updated: clamav-filesystem-0.101.0-1.el7.noarch Jan 04 16:42:48 Updated: clamav-lib-0.101.0-1.el7.x86_64 Jan 04 16:42:48 Updated: clamav-update-0.101.0-1.el7.x86_64 Jan 04 16:42:48 Updated: clamd-0.101.0-1.el7.x86_64 Jan 04 16:42:48 Updated: clamav-server-systemd-0.101.0-1.el7.x86_64 Jan 04 16:42:48 Updated: clamav-scanner-systemd-0.101.0-1.el7.x86_64 Jan 04 16:42:49 Updated: clamav-0.101.0-1.el7.x86_64 Jan 04 16:42:54 Updated: clamav-data-0.101.0-1.el7.noarch Jan 04 16:42:55 Updated: python2-certbot-apache-0.29.1-1.el7.noarch # Sendmail hasn't had updated packages in a long time, since August 2017. None of the package scriptlets from the above packages look like they would affect the sendmail setup. So, I'm looking for suggestions on where to start looking for the data to ferret this out; no clues are in /var/log/messages or /var/log/yum.log. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 7 + GNOME : all icon themes broken after update from CR
On 11/20/18 8:48 AM, Johnny Hughes wrote: On 11/18/2018 09:01 AM, Nicolas Kovacs wrote: Le 18/11/2018 à 15:30, Lamar Owen a écrit : I did the update from CR, and have some pretty serious issues. ... Since Red Hat decided to roll in some major GNOME updates between minor releases, I'm seriously beginning to wonder if I won't be better off using Fedora on desktops. ... There are new gnome-session and gdm updates that I am getting ready to push to CR .. gnome-session-3.28.1-6.el7.src.rpm and gdm-3.28.2-10.el7.src.rpm .. no idea what the actually do yet, but you can see if they fix any of your issues by looking at the upstream errata, etc. Well, reporting back, and I'm not 100% sure what caused my problem. I have used several repos since I installed the box two years ago, and there was quite a bit of clutter. I'm leaning towards my use of xscreensaver (I like the 'flurry' screensaver) as the likely culprit, but I had enough clutter that it's not really practical (not to mention that I really can't take the time) to fully troubleshoot and be close to 100% sure. Since I did have some clutter to deal with, and the drives (250GB mSATA SSD and 1TB HGST 7K1000) are two years old at this point, I decided it was time to refresh my installation. So I got a good deal on a Samsung 860 EVO 500GB mSATA and another HGST 7K1000 (one of the best 2.5 inch drives out there), and waited until they came in to do a complete reinstall, and am rsyncing files over from the older 1TB drive as needed. The Dell Precision M6700 laptop has two 2.5 inch bays plus the mSATA slot, so I downloaded the 1804 DVD iso (mirrors must be syncing; the download took way longer than it should have!), installed to the 860 SSD with the 1TB as /home (leaving the old 1TB /home alone), and successfully updated with CR afterwards. The install of the ELrepo nvidia driver went smoothly, and after some install work and rsync work I'm back operational; a USB 3.0 enclosure for the older mSATA boot drive made it much easier. I spent more time trying to troubleshoot GNOME3's startup than it took to install and update! In a related vein, does anyone have a pointer to a good solid GNOME3 startup document that gives enough detail to where someone can actually troubleshoot without having to patch and rebuild gjs and stack trace javascript? Just a simple startup log woul be nice, instead of the SIGSEGV in /var/log/messages. (side note: I really hate how the Android GMail messes up threading; the Samsung email app is better, but it can't properly display a lot of the messages in the CentOS list (such as Johnny's) and GMail can) ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 7 + GNOME : all icon themes broken after update from CR
I did the update from CR, and have some pretty serious issues. Until I blew away (by mv to a different name) the .local and .config directory trees, I couldn't log in to GNOME at all. After doing that, I can log in, but if I do any actual work, GNOME crashes, and abrt-cli from root in vc 2 tells me that gnome-shell got a SIGSEGV. I figure all of the updates aren't in CR yet, so I'm going to pull out my backup machine and work with it until I see if CR gets more updates. Good thing I've got vacation scheduled for next week!I did quite a few other things in trying to troubleshoot, including attempting a yum distro-sync without CR enabled, which had helped me rollback once before, but not this time. Once I get my backup machine set up I can post better details. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Vmware - Slightly off topic
On 04/24/2018 01:26 PM, Jerry Geis wrote: What is the correct way to provide a CentOS 7 - WMware image for ESX ? ... I just want to be able to provide a pre-built image with CentOS 7 and my other programs on a bootable VMware image that is easily imported into any VMware platform - Workstation, ESX or other. How is that accomplished ? Thanks for your thoughts and experience. While my experience with ESX is rather old at this point, as is my experience with Workstation, since I have converted to KVM for my virtualization here, I will just point out that the virtual hardware supported by ESX(i) and Workstation are not the same. I don't know if current vSphere/ESXi is different, but it's easy enough to check, but older ESX only supported SCSI for the virtual hard disks; no IDE hard disk support in ESX, and Workstation defaults to IDE hard disks. VMware Workstation and ESXi are very different products, or at least the last versions of each that I actively used were. So check which ESXi version you're targeting, and make sure you install the guest in Workstation with that hardware version and with ESXi-compatible devices. And then there is VMware Fusion for macOS ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Down C6 ALL without torrent ?
On 04/18/2018 09:58 PM, Always Learning wrote: ... It would be nice to have everything (part 1 and part 2) on the same bootable USB stick. You should be able to install most things with just DVD1, and there are good instructions on the CentOS Wiki about how to go about generating the USB stick ( https://wiki.centos.org/HowTos/InstallFromUSBkey ), although I use ddrescue over just dd since it will optimize the blocksize for a bit faster read and write. There is a CentOS Wiki article on the subject of merging split ISOs into a single ISO; see https://wiki.centos.org/TipsAndTricks/CDtoDVDMedia (this covers merging multiple ISOs into a single ISO, which was originally most useful for taking multiple CDs and making a single DVD, but also works for merging two DVD ISOs into a single DVD ISO; I have used this script before). Note that some have reported 'Insert Disc 2' prompts during kickstart installations, so it is possible that if you select something that is on DVD2 it may ask for DVD2 during install; I haven't tried it in so long that I don't know what it will do with current CentOS 6. I used this scripts years ago for merging CentOS 4 and 5 media to DVD for installation, and the basic structures in C6 still work with it. You need 3X the space of the full distribution size; enough for the two source DVDs, plus the unpacked package tree, plus the output single DVD. As to DVD installation, are you sure the server has a DVD drive and not just a CD drive? (I have run into this before, with a fairly recent server). I have also run into media compatibility issues where the DVD-ROM drive would not read the DVD media I was using; I have also run into DVD drives being sensitive to +R versus -R as well as the speed of the DVD writing. DVD writers will have better compatibility, and most servers can have those as options if an optical bay is even included. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Ubiquiti Model UAP-AC-PRO
On 02/27/2018 08:31 AM, Bill Gee wrote: 1) The resolution of "unifi" by DNS is to the machine hosting the Unifi Controller software. Is that correct? Yes, that's correct. How did you add an FQDN of "unifi" to your DNS? I added a new zone to /etc/named.conf for the ZONE 'unifi' pointing to a host file 'unifi.hosts' containing an A record for 'unifi.' as well as the SOA, NS, etc records. That trailing dot is important. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Ubiquiti Model UAP-AC-PRO
On 02/15/2018 08:41 PM, Gregory P. Ennis wrote: It looks like the setup requires the use of software; they have some packages that are ready made for Ubuntu and Debian, but not RedHat https://www.ubnt.com/download/unifi/unifi-ap-ac-pro Have any of you tried or succeeded in installation this on Centos 7.4? I have several Ubiquiti UniFi access points (nitpick: they're not routers, but access points) on the LAN here: 2 UAP-AC-HD, 5 UAP-AC-Pro, and 4 UAP-AC-MeshPro outdoor units. The UniFi controller is very handy for administering these access points, and, for this many over a network of our physical size it is absolutely necessary. And these APs have proven solid; last year for the solar eclipse we provided WiFi on two separate systems for over 1,300 people, and both systems held the load (public WiFi was on a loaned Cisco Meraki system, while staff, volunteer, and VIP WiFi was on the Ubiquiti. Those UAP-AC-HD access points are killer good!). I rebuilt from source the RPM packages linked in the message on the Ubiquiti forum at https://community.ubnt.com/t5/UniFi-Wireless/Unofficial-RHEL-CentOS-UniFi-Controller-rpm-packages/td-p/1744595 I am currently running 5.4.16 here, but have a 5.6.x at another location, which is working fine, but to administer some Ubiquiti switches, not APs. One of the key things to getting this to work really smoothly is to provide local-only, on-site authoritative DNS for the FQDN of 'unifi.' Yes, as a top-level domain, the single word 'unifi' needs DNS for the AP's to be really happy and for AP adoption to work seamlessly without having to ssh into the AP individually and do a 'set-inform' to the IP address or FQDN of the UniFi controller. You can do this with /etc/hosts, but putting the zone in there for your loacl recursive resolver makes it really seamless. There are also some firewalld settings to do, opening some ports. Here are mine for the running 5.4.16: [lowen@dhcp-pool157 ~]$ ssh root@unifi Last login: Mon Feb 26 11:49:12 2018 from dhcp-pool157 [root@b1dc-bc1-1-hs21 ~]# firewall-cmd --list-ports 8443/tcp 8080/tcp [root@b1dc-bc1-1-hs21 ~]# cat /etc/centos-release CentOS Linux release 7.4.1708 (Core) [root@b1dc-bc1-1-hs21 ~]# Layer 3 adoption works fine with this set of firewall ports open; none of my AP's have Layer 2 adjacency to the controller, so the set-inform URL either needs set or DNS needs to resolve the 'unifi' FQDN to the controller for discovery and adoption to succeed. The 5.6.30 controller system I installed last week at a different site shows a larger set of ports open: [root@c6-2850 ~]# ssh root@unifi Last login: Mon Feb 26 12:08:12 2018 from 10.1.1.3 [root@files ~]# rpm -qa|grep unifi unifi-controller-5.6.30-1.el7.centos.x86_64 [root@files ~]# firewall-cmd --list-ports 8443/tcp 8080/tcp 8880/tcp 8843/tcp 3478/udp [root@files ~]# cat /etc/centos-release CentOS Linux release 7.4.1708 (Core) [root@files ~]# (for what it's worth) ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Firefox print to file fail silent & side notes of cms4all.
On 11/06/2017 05:08 PM, Andreas Benzler wrote: Hello everyone, in time when i start to rebuilt my csm4all-media, I tryed to print into file from firefox. The print box close but no pdf is created. While attempting to print to PDF today I ran into this same issue. It's SELinux throwing the error, and here is what setroubleshoot suggests: "SELinux is preventing java from write access on the file /home/lowen/Documents/personal/printed-copy.pdf. * Plugin mozplugger (99.1 confidence) suggests If you want to use the plugin package Then you must turn off SELinux controls on the Firefox plugins. Do # setsebool -P unconfined_mozilla_plugin_transition 0 " I made a physical print for now, as I'm going to investigate a bit before I blindly enable a boolean like that. See also https://www.centos.org/forums/viewtopic.php?f=48=63781 and https://bugzilla.redhat.com/show_bug.cgi?id=1430037 (CLOSED NOTABUG) There are several mozilla-related SELinux booleans: [lowen@dhcp-pool101 ~]$ getsebool -a|grep mozilla mozilla_plugin_bind_unreserved_ports --> off mozilla_plugin_can_network_connect --> off mozilla_plugin_use_bluejeans --> off mozilla_plugin_use_gps --> off mozilla_plugin_use_spice --> off mozilla_read_content --> off unconfined_mozilla_plugin_transition --> on [lowen@dhcp-pool101 ~]$ ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Failed attempts
On 11/28/2017 12:04 PM, Valeri Galtsev wrote: Thanks, Lamar! that is very instructive. You're welcome. I was always unimpressed with persistence of attempts to make more secure (less pickable) cylinder cased locks (precision, multi-level, pins at a weird locations/angles). The best way to make an unpickable lock is to make the tolerances of the pins and the cylinder bore as tight as possible, since picking relies on part tolerances to work. But several sidebar designs are out there that are pretty hard to pick, including Schlage Primus, the various Medeco styles, and others, such as the Kaba dimple locks used on Cisco Metro 1500 DWDM gear for power switches (the lasers are powerful enough to permanently damage your eyes in short order in those). Whereas there exists "disk based design" (should I say Abloy?), ... I had an old Bell System payphone with Abloy locks. Very difficult to bypass or pick, and requiring very different techniques than are used with pin-tumbler locks. There were two locks: one on the coin door (activated four large rectangular bolts, one on each side, with the only common point that could be successfully drilled being the lock cylinder itself), and one on the door to the circuitry (which included the programming port to set the per-call rate for use with a standard subscriber line, instead of the dedicated pay lines, as well as the coin-counter electronics). They were used on many payphones twenty years ago or so. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Admins supporting both RHEL and CentOS
On 11/28/2017 08:06 AM, Joseph L. Casale wrote: What is the case with users on this list who support both [rolling releases like the normal CentOS model and 'constrain to the point releases' as is possible with RHEL]? I personally run RHEL just like my CentOS installs, as a rolling release. If you want to get more input on this idea, you might want to also ask the Scientific Linux mailing list, since SL can be run in a 'constrain to the point release' mode with full security updates maintained, and you're likely to get a broader response base as to why this is done. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Failed attempts
On 11/27/2017 02:02 PM, m.r...@5-cent.us wrote: Pete Biggs wrote: - don't run ssh on 22, use a different port. I consider that pointless security-through-obscurity. Security through obscurity it may be, but it isn't pointless. Tarpits are in a similar class; they don't help with security in the absolute sense, but they slow the attacker down, and that might be enough to prevent the attack from continuing. (that is, put a tarpit on port 22 and run the real ssh elsewhere!) Any and all stumblingblocks you can put in the attacker's way, whether they're 'real' security or not, are worth at least looking at and evaluating their usefulness. Port knocking is an extreme form of security through obscurity, in reality, and falls into this class of tools. Likewise fail2ban; all it really does is slow down the attacker. No, obscurity-increasing tools will not stop the determined attacker, but, it is very true that these sorts of measures can and do increase the signal-to-noise ratio in your logs; what does get logged will likely be much more useful and indicative of a more determined attacker. Anything that substantially increases the log's signal to noise is useful and not pointless, in my opinion. Anything that slows down the attack is even more useful. I actually have training as a locksmith, with a specialty in masterkeying systems like rotating-constant and some obscure variations of RCM (this is one of the two masterkey systems explored in the infamous (in locksmith circles) paper "Cryptology and Physical Security: Rights Amplification in Master-Keyed Mechanical Locks" by Matt Blaze [1] [2]). In physical security all security is, in reality, through obscurity [3] (page 2, first paragraph): things like keeping the drill points secret (example: in a pin-tumbler lock, if you can drill the shear line, you are in; but what if you have extra pins and hidden shear lines?), keeping secret what materials are used for the hardplate and their interactions with commonly-available drill-bit materials [4], having a strategically placed and hidden tear gas vial [5], etc (all of this information is publicly available; I'm not spilling any real locksmith secrets here). The real key to effective physical security is not keeping the attacker out in an absolute, 'can't possibly break in' sense, but buying time for response to the attack; as the attack continues to eat time, the attacker will have increasing incentive to leave the premises. Now, if you want a real eye-opener about physical security, grab a copy of "OPEN IN THIRTY SECONDS" from Amazon [6]. That and the key reference, Marc Weber Tobias' LSS (Locks, Safes, and Security [7]) are fascinating (if expensive) reading and great resources for the syadmin who wants to dig into what is really meant by a security mindset. [1]: http://www.crypto.com/papers/mk.pdf [2]: http://www.crypto.com/masterkey.html [3]: http://www.crypto.com/papers/safelocks.pdf [4]: https://reassembler.wordpress.com/2008/02/04/drilling-into-a-modern-safe/ [5]: http://www.lockpicking101.com/viewtopic.php?f=8=16891 [6]: https://www.amazon.com/OPEN-THIRTY-SECONDS-Cracking-America/dp/0975947923 [7]: https://www.amazon.com/Locks-Safes-Security-International-Reference/dp/0398070792 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Comparing directories recursively
On 10/27/2017 05:27 PM, H wrote:
What is the best tool to compare file hashes in two different
drives/directories such as after copying a large number of files from one drive
to another? I used cp -au to copy directories, not rsync, since it is between
local disks.
I typically use 'rsync -av -c --dry-run ${dir1}/ ${dir2}/ ' (or some
variation) for this. rsync works just as well on local disks as
remote. This isn't as strong of a comparison as even an md5, but it's
not a bad one and gives you a quick compare.
You can even use git for this: 'git diff --no-index ${dir1}/ ${dir2}/'
and that would be a stronger comparison.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] How to encourage maintainers to update their software
On 10/28/2017 01:28 PM, Japheth Cleaver wrote: It didn't seem to use to be that case. IMO it makes a lot more sense to wrap distro-specific .spec file changes in conditionals and let the rpmbuild do the right thing than to post and maintain separate versions for Fedora, EPEL, and anything else. In my former role as package maintainer for the PostgreSQL development group several years ago, I was contracted to do RPMs for several different distributions. And while this was several years ago, the basic RPM mechansims have not changed that significantly, and this kind of maintenance can become a rat's nest nightmare very quickly. I found that, specifically for PostgreSQL, the complexity increase was not linearly proportional to the number of distributions and versions of distributions supported; rather, it was much more like a cubic or quartic relationship with multiple poles and zeroes (using Z transform terminology) and pitfalls everywhere. The current PostgreSQL RPm maintainers do a great job supporting what they do, but it is not easy at all to support more than four distribution versions with one spec file. Now, this thread is also talking about doing your own rebuilds, and, to a point, this works quite well. Especially in cases where the EPEL maintainer simply refuses to update a package because it would cause a version bump of that particular package and 'version bumps require Deep Reasons' (paraphrased from an actual response). My experience maintaining the PostgreSQL RPMs prepared me well for some of the things I have rebuilt (such as kicad) on C7. HOWEVER, there is a hard and fast and totally inviolate rule to rolling your own rebuilds: "You break it, you keep it." You are taking your own system's stability into your own hands; for some packages (like kicad, or gnuradio, or other relatively stand-alone packages that don't require major shared library replumbing) it's fairly easy and safe to do your own builds; for some packages it is going to be nearly impossible if the packages' upstream developers haven't made it easy to locally build their dependencies with the sometimes very specific version requirements (case in point: Ardour). And some of these packages have no security footprint as far as updates are concerned (web browsers and email clients absolutely have major security footprints and need to stay updated, but something like kicad does not). There are automated tools to do these sorts of things, such as the perl script 'smock' which does a reasonable job doing source build dependencies, as long as the buildrequires deps in the source RPM are proper and there are no hidden ones (experienced RPM rebuilders know I say that a bit tongue in cheek). Whatever you do, do NOT rebuild as root. Mock and similar tools make it possible to have reproducible builds, and it is strongly encouraged that these tools be used. BUT, again, "you break it, you keep it" applies strongly because that package you built might have required a package that isn't currently in C7 but might be added at some future date, and your hand-built package might cause a real security update to fail in weird ways. Caveat aedificator, perhaps? You are then responsible to keep your hand-built dependency updated yourself. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] /var/run/... being deleted :((
On 10/13/2017 10:19 AM, Anand Buddhdev wrote: .. Stop trying to force a square peg into a round hole. Whee, I just _know_ I'm going to be positively skewered (and maybe even plonked!) for this but, hey, it's Friday, and this post is meant to be a bit funny. So lighten up, and enjoy a short read. obHumor: I actually have a piece of furniture (a small table) with square pegs in round holes. The spaces between the sides of the square peg and the round hole are filled with a color-contrasting glue, and the result is rather pretty. :-) I intentionally picked this furniture specifically because of the square pegs in the round holes. obHistory: Cobblers making boots back in the mid to late 1800's would often use square wooden pegs in round leather holes (typically for the thick leather soles of the boots) so that the peg would 'swage' it's own hole and fit tighter, thus holding better than a round peg ever could. (Reference: "Farmer Boy", Laura Ingalls Wilder, Chapter titled 'Cobbler' (hey, I have five kids; my wife and I have read through the whole series five times!) which, after reading through it with my eldest child back in 2000 or so I decided to never use the 'square pegs in rounds holes' proverb ever again!). (There are other historical instances of square pegs being better for round holes than round pegs, especially when you didn't want the peg to rotate in the hole). Anyway, a form of pseudo-persistence that meets the OP's needs is already supported directly by systemd-tmpfiles, which is a part of the core systemd package and non-optional, so your vehement disagreement is moot, sorry. The round hole already has a square-peg adapter, at least in CentOS 7. Packagers just need to select the proper 'adapter' for systemd-tmpfiles; the adaptation is not (and should not be, in my opinion) automatic. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] /var/run/... being deleted :((
On 10/13/2017 10:02 AM, Michael Hennebry wrote: I see at least two possible intermediate results: The RHEL 7 folks do something, perhaps make a package, to make pseudo-persistence super easy to get. ... This already exists as systemd-tmpfiles, as was mentioned in the thread by someone else. Any packages needing anything to be initialized in /var/run (sockets, named pipes, etc) should use that mechanism for those things to be created each boot; that's why I used the term 'pseudo-persistence' as the persistence of this information is a mirage. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] /var/run/... being deleted :((
On 10/11/2017 03:42 PM, Alice Wonder wrote: When I need daemon (or other not human user) produced data to persist a reboot, I use /srv - I don't know if that is technically correct or not, but it seems highly unlikely /srv would ever be a candidate for wipe on boot. Perhaps the package in question could simply be patched to use /srv ?? Hmm, not a bad idea actually, although historically with 'Old Unix (TM)' I would probably use /usr or /var/lib (if it's new enough to have /var/lib). Yes, /usr, not /usr/lib or /usr/share; my first Unix system place user home directores right off of /usr (I had my /usr/lowen from my Tandy 6000 Xenxi system on 30 8-inch floppies once; kindof wish I had those again, although enough of them would probably be unreadable so I would lose some segments of the multi-floppy tar; but the readable segments could still be restored, since it was an uncompressed tar.). Today I would say a directory tree right off of /var or /srv wouldn't be inappropriate. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Flame war police
On 10/11/2017 04:05 PM, Mark Haney wrote: On 10/11/2017 02:44 PM, Lamar Owen wrote: Hi Mark, been a while since I saw you last in Asheville. Hey Lamar, long time no see. ... [snip] Yeah, too long. Come by and visit some time. The core issue in the /var/run thread is one of lack of civility. ... I do agree, to a point. Being Irish, my temper is always simmering, usually over ignorance or willful stupidity. I'm Irish, too, and that's why I have to set the protocol for myself that I do, and many times I'll let a post sit in a compose window half the day before I cancel it (or send it, as the case may be). I've had to perform podondectomies too many times. (surgical removal of foot from mouth.) If you never put the foot in your mouth, you never have to remove it. But, sometimes you just have to be the bad guy when people are recalcitrant. ... Right or wrong, I stand by it. Ok, fair enough. And I wasn't singling you out by any means; since I actually know you personally I figured you wouldn't mind my using your post as the reply point. I get it. I really do. And there were times I probably should have walked away from the entire thread. But, I want people to learn, and learn the right way (regardless of the multitude of 'right ways' in our line of work) and you just have to be very firm with those digging their heels in, if, for instance, they are in a position to do real harm, to data or otherwise. People tend to dig in their heels when they're being dragged a direction they don't want to go But, again, I'm not by any means singling you out. Some people, as I have learned the hard way with my eldest two children, just have to learn things the hard way. I'll share my experience; but in the end some people have to lose data to understand why some things are they way they are. And I might be doing them a favor in the long run by letting them. But maybe I'm just too fatigued these days. I just get tired of dragging anchors and pushing chains. Anyway, hope all is well with you and PARI. I need to get back down there with telescope sometime, the light pollution in RDU is just awful. Thanks; let me know when you come up and I'll show you around at some of things that have changed (like our Redstone rocket engine on display, and the ATS-6 satellite on loan from the Smithsonian). Just don't try to get any information right now from our website; it's down due to a double failure on our ISP's fiber ring; redundancy works great, until you get two trees 50 miles apart that decide to crash down on your fiber within two hours of each other, taking out connectivity in both directions. Give it a few hours. Let's take any more replies off-list, though. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] /var/run/... being deleted :((
On 09/21/2017 08:14 AM, hw wrote: what keeps deleting files and directories under /var/run? Having them deleted is extremely annoying because after a reboot, things are suddenly broken because services don´t start. You've received a lot of advice, criticism, and information from this original post, and I'm not going to rehash any of those things. If you're not expecting it,the current CentOS 7 behavior could easily be jarring, to say the least. I empathize with your situation; the release notes are large, dense, and it's easy to miss something that has been changed, like this behavior (or like the need to 'yum downgrade' a packge to get a 'yum update' to complete). However, whether we like it or not, CentOS is a rebuild of the sources for the upstream enterprise Linux. The underlying issue is one of two different package maintainers having differing ideas (as well as two differing interpretations of admittedly ambiguous standards) of what the system should do. If I see two reasonable, competent, system administrators disagreeing about the interpretation of a standard, then the standard is ambiguous. Now, I'm not going to pass judgment on whether it's a bug or a feature, nor am I going to say which I think it is, because what I think or feel about it won't change the reality of the situation; this distribution is way too far down the development curve now -- the time to express those opinions where such expression might have made a difference in the reality of the situtaion was back while the change was being considered for Fedora, and that was a long time ago. The fact of the matter is that the EL7 behavior is to store /var/run in a temporary way, and that's not at all likely to be changed in EL7, regardless of the opinions I have or express about it or what expletives I choose to call it. EL7 includes mechanisms so that files, directories, sockets, named pipes, or whatever that need to look like they persisted across a reboot in /var/run can be recreated at boot as needed, and the packages you use do not yet use that mechanism. If the maintainers of packages that want to run well on CentOS 7 need to have /var/run/$some-file persistence (or pseudo-persistence, which is the current behavior enabled by re-creating said files) then those maintainers will need to change their packages to match actual behavior or file a bug report with upstream to change the behavior. Upstream will probably close with a 'WONTFIX' and the package maintainer will either change packaging or stop supporting CentOS 7. Of course, stranger things have happened, and upstream might relent on the decision. But my gut feel is that upstream will keep the current behavior and the packages will eventually be changed to support it, but I always reserve the right to be wrong. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Flame war police
On 10/10/2017 11:22 AM, Mark Haney wrote: We have this discussion on every list I've ever been, or currently are on about every 6 months or so. I do my best to contribute to the list as often as I can, but I can't help people when they are deadset on doing dangerous things. Posts like his, and posts like yours make it harder for me to bother trying to help those unwilling to listen. I don't take it from my children, and I certainly won't from adults who won't listen. Hi Mark, been a while since I saw you last in Asheville. The core issue in the /var/run thread is one of lack of civility. There is a civil way of calling someone to see their need for further thought and investigation; calling someone 'stupid' or 'an idiot' over something as small as /var/run directory persistence is, to my mind at least, its own brand of immaturity and will typically cause the person so being attacked to go on the defensive and harden their stance, and this is the textbook genesis of a flame. I've been involved in Unix and related pursuits long enough to know that different people consider different things to be polite. And I've said my share of impolite things, especially back in the day when I had a Usenet leaf node over uucp and participated in news.admin and alt.flame, so I'm not being self-righteous here, just practical and realistic. I've been plonked before, and I've plonked before. (If anyone isn't familiar with the term 'plonk' it means to put in your killfile or ignore list, and there are a few people that have been on this list that I have killfiled in the past, several especially right around the releases of CentOS 5.6 and CentOS 6.0). So, for the last several years, I have set a protocol for myself where, if words that would be considered uncivil by most people were present in my post, or if my wording became too much of an attack over the person, I simply don't send it. My wife and I have five children, so I'm more than a little familiar with a certain rabbit named Thumper and his famous adage "f you can't say something nice, don't say nothin' at all." Now, I don't agree with that adage as written, as I would rather use the word 'civil' instead of 'nice,' because 'civil' doesn't mean nice. Civil just means 'not nasty' even when you need to have 'Radical Candor.' But I reserve that sort of 'harsh civility' for my staff here when necessary, who get a much more civil tone than my children at home would, incidentally. But my staff aren't children. And the members of this list aren't my staff, and I will be civil to everyone on this list. I'll drop a brief note about my opinion of /var/run later, so that anyone who wants to ignore that thread before I post can do so. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] /boot partition too small
On 10/10/2017 09:20 PM, Robert Nichols wrote: For you, there really is no way around the messy and delicate process of shrinking and relocating a filesystem and the LVM volumes to make space for a larger /boot partition. Frankly, I would hesitate to do that in place on my own system, and I have quite a bit of experience with doing unspeakable things with LVM volumes. You really need to do that resizing in the context of moving everything to another disk. Agreed. If / and /home are on xfs you can't shrink anyway. I'm not sure if ext4 can be shrunk while mounted (I seem to remember that it can't). If it's a server that you don't want to take down for the time it takes for that procedure, you can do amazing things with pvmove while your system continues to run, but you still need another disk to hold those volumes temporarily. As long as there is enough slack space in the volume group you can do this. If there is no slack space you have real problems, especially with XFS (one reason I still use ext4 for many things, and one reason I never fill the volume group to 100%). I have done the pvmove and filesystem resize dance before, live, with the second hard disk attached via iSCSI. The least fun piece is then resizing the /boot partition and its filesystem. But I had enough slack space in the volume group. What can be done here is unmounting /home, shrinking /home the appropriate amount, and then you have enough slack space to do the shrink and move (not fully live, but semi-live, and you can't have any logged-in users with open files in /home). Shrinking from the end of the filesystem and pv is easy; shrinking from the beginning is hard and prone to errors. (gparted and similar do the move of the end of a partition fine; moving the start is much much harder). However, if you can shrink enough from the end you can put /boot on the last partition on the disk instead of the first, although you will have to do some grub stanza editing to get rid of /dev/sda1 and replace with the appropriate device for the new /boot. So you could shrink /home, shrink the pv, shrink the partition holding the pv (this is the risky part), then add a partition to the end of the disk for the new /boot. If you've never done this sort of thing before you may want to get someone who has done this sort of thing to do it. Otherwise, if you feel at all uncomfortable doing this it may just be easier to pull a backup and reinstall. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 7.4.1708 dependency problems
Greg, according to the release notes "Known Issues" section ( https://wiki.centos.org/Manuals/ReleaseNotes/CentOS7?action=show=Manuals%2FReleaseNotes%2FCentOS7.1708#head-281c090cc4fbc6bb5c7d4cd82a266fce807eee7c ) you need to run "yum downgrade libgpod" first. I have updated a dozen or so machines to 7.4.1708, and several needed this. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Update to 7.4 using DVD
On 09/13/2017 04:40 PM, Jerry Geis wrote: I am running the propriatry NVIDIA driver 384.69 for GT 720 support. The ELrepo driver works very well for me with CentOS 7.4.1708 on a Dell Precision M6700. Here's what I have: ++ [lowen@localhost ~]$ nvidia-detect -v Probing for supported NVIDIA devices... [10de:11be] NVIDIA Corporation GK104GLM [Quadro K3000M] This device requires the current 384.59 NVIDIA driver kmod-nvidia [lowen@localhost ~]$ rpm -qa|grep nvidia nvidia-x11-drv-384.69-2.el7.elrepo.x86_64 nvidia-detect-384.59-1.el7.elrepo.x86_64 yum-plugin-nvidia-1.0.2-1.el7.elrepo.noarch pcp-pmda-nvidia-gpu-3.11.8-7.el7.x86_64 kmod-nvidia-384.69-1.el7_4.elrepo.x86_64 [lowen@localhost ~]$ (nvidia-detect hasn't yet been updated to .69..) The ELrepo team does a great job with this driver; unless you have a compelling need to rebuild it yourself (I hesitate to say 'recompile' as, well, there's very little to actually compile) you should investigate using the ELrepo.org modules that make these sorts of updates much easier. Thanks ELrepo for the modules; thanks CentOS project for the rebuilt OS. The ELrepo nvidia driver handles the nouveau disabling as well; it's seamless, and works. The only caveat is when your card goes to the legacy driver, at which time you'll have to install the legacy version; ELrepo builds those too. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Odd switch of running MTA during update through CR to 7.4.1708
Ok, had a real oddity here, and am working to track it down. I've done a few updates to 7(1708) via CR at this point, and hadn't had any real issues, so during a slack time today updated our email server. Now, prior to the update, I had our email server set up with postfix, but after the update the system had sendmail enabled and postfix disabled. Like I said, I'm still looking into it, but just a heads-up. A 'systemctl disable sendmail; systemctl stop sendmail' then 'systemctl enabled postfix; systemctl start postfix' seems to have restored things. I would probably be well-off to remove sendmail altogether, but I would have thought that the startup settings would have been honored anyway. -- Lamar Owen Chief Technology Officer Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 828-862-5554 www.pari.edu ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] What RH-like on a Dell XPS 15 (9590)?
On 07/27/2017 04:16 PM, wwp wrote: ... It is as simple as unknown hardware at boot up, it's a well known issue w/ *Lake hardware (modern hardware) that kernel 3.x cannot handle. CentOS7 has a kernel which is simply not modern, unable to handle lots of computers sold currently. That said, there might be a way to boot, but nothing trivial and nothing at all I could find on the Internet, everytime it's kernel 4.3/4.10 minimum required. ... While I know that Johnny has provided the experimental kernel (thanks, Johnny) I would like to just briefly address this idea that the C7 kernel is 'obviously' not going to work because 'is 3.x and must have 4.x.' In EL-land, kernel versions are effectively meaningless, since features, hardware support, bugfixes, security fixes, etc are back-ported into the 'old and not modern' 3.10 kernel (for EL7) by competent developers at Red Hat. An EL 3.10 kernel, such as the current 3.10.0-514.26.2.el7.x86_64 one, may have hardware support back-ported from a 4.x kernel that doesn't exist in the vanilla kernel.org kernel (I'm almost certain it does, but I'm not going to take the time to get details). So it is very possible that full hardware support for your hardware could show up in a 3.10 kernel (in fact, I would expect that this would happen, but it might not happen quickly). As you found out, experimental kernels and non-distribution kernels can freak out software packages, such as VMware Workstation, that only work with certain kernels and are expecting a particular kernel version and ABI for EL7. I've tried out a few non-standard kernels before, and if you rely on packages that depend upon the distribution default kernel version (as I do with kmod-nvidia from ELrepo!) that breakage can be swift, and can derail you in a hurry, causing you to go down a rabbit hole very quickly. So be prepared and keep your eyes open for these issues. In some circles, the back-porting of features into old kernels is controversial; but that is a business decision made as part of the EL development and is not likely to change any time soon. YMMV. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS SDR Support
On 07/19/2017 11:02 AM, Chris Olson wrote: We have been following up with regard to how SDR capabilities might be used for obtaining time using SDR dongles as well as using the time source product referenced in that response. ... One thing that we did not find was any reference at all to SDR products and software for monitoring the frequencies used by recreational Remote Controlled Aircraft. GNUradio works well on CentOS 7, but it is a bit of an adventure to get it built. Marcus Leech's build-gnuradio.sh script works fine, and I've used it several times to build GNUradio on C7, both on x86_64 and on aarch64 (although I haven't performed that build on any of my ODROID C2s in some time and it really was a pain due to EPEL not being available for aarch64 at the time). I tried the PyBOMBS build, but it wasn't successful for me, so I reverted to the build-gnuradio.sh script. GNUradio supports a number of SDR dongles, including the RTL-SDR. An old version of GNUradio used to be in EPEL, but it's no there as of today. For general-purpose SDR work GNUradio is fine, but if you need deterministic latency you may be disappointed. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Firefox 52.2.x and javascipt issues
On 07/05/2017 03:27 PM, Bernard Lheureux wrote: Hi all, Is it me or there are a lot of troubles with Firefox ESR 52.2.x and javascript ??? I face a lot of troubles with pages I used before correctly running javascript, since the update to firefox-52.2.0-1.el7.centos.x86_64 on my EL7 laptop The latest update does seem to have caused some issues for me as well. Certain sites (the Autodesk EAGLE site was one of them) seem to just about completely hang with current Firefox for me. Might have something to do with having NoScript loaded; NoScript had an update within the last few days that seems to have fixed the Autodesk EAGLE site issue. The issue manifested itself with a nearly completely hung tab, and all other tabs hung as well, with nothing clickable. Clicking the X to close the tab took thirty seconds to a minute to close; clicking X to close Firefox completely took close to a minute to close. System specs: Core i7-3740QM with 16GB of RAM and an SSD system drive. It's not due to a slow system. I haven't experienced the issue since NoScript updated yesterday, so maybe that was related. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] System Time Source
[Going a bit off-topic here, and going to do a bit of a deep-dive on RF
stuff, but maybe it will be useful to Chris]
On 05/24/2017 12:20 PM, Valeri Galtsev wrote:
It is insightful, yet... There are a bunch of other factors that may need
to be taken into account. Angular transmission pattern of satellite (horn?
or is it yagi? antenna) vs ground based (monopole? or dipole? antenna -
which one is used there to transmit in HF?).
WWVB uses a two-element phased array, where each element is a 400-ft
top-loaded vertical monopole. The ERP is listed as 70kW, so the antenna
gain is already applied to the transmitted signal's specification and
thus doesn't need to be considered. (Lots of technical data can be found
in NIST's report on the 1998 upgrade:
http://ws680.nist.gov/publication/get_pdf.cfm?pub_id=50031 ).
Please see http://gpsinformation.net/main/gpspower.htm for the relevant
data on GPS (25.6W output, 13dBi gain, EIRP 27dBW (about 500W), free
space loss of 182dB, -130dBm receive signal strength (0.1 femtowatts, if
I've done the calculation correctly)).
Ground effect (attenuation)
along the whole path or propagation for ground based HF vs ground effect
only at the receiption point, but much higher for much higher frequencies
of GPS; pre-amplifier Signal to Noise ratio (S/N; which can technically be
achieved to be much better at much higher GPS frequencies...).
WWVB's signal is at 60kHz, which is LF, not HF. LF signals are not
significantly attenuated by ground conductivity effects, so a simple
inverse-square-law free-space path loss calculation is a close
approximation; the loss to a point halfway around the world (~20,000 km)
is about 94dB (82dB for 5,000km); the ERP is 70kW (78.45dBm); the
minimum power available anywhere on the surface of the world is
-15.55dBm, or 0.03mW and the minimum power available within 5,000km is
about -3.55dBm, or about 0.44mW. Half a milliwatt is quite a bit to
work with, excepting the noise effects of 1/f ("pink") noise and local
interference. Higher-gain receive antennas are easy at 60kHz (iron-core
loopstick or a multi-turn loop). According to NIST's site, however,
WWVB is currently running at half-power (35KW ERP; 75.45dBm) so cut the
available power in half at the moment.
However, WWVB's signal _is_ 60kHz, and so any building of metal
construction, even sparse-spaced rebar in concrete, will effectively be
a very high attenuation 'waveguide-beyond-cutoff' attenuator, and so a
very effective shield, even with the very high power available to the
receiver.
GPS receiver module manufacturer u-Blox has an informative paper on GPS
receiver antenna design that might answer some other questions:
https://www.u-blox.com/sites/default/files/products/documents/GPS-Antenna_AppNote_%28GPS-X-08014%29.pdf?utm_source=en%2Fimages%2Fdownloads%2FProduct_Docs%2FGPS_Antennas_ApplicationNote%28GPS-X-08014%29.pdf
I'm running an NTP setup here with our secondary being a CentOS box
using an Agilent Z3816 GPS-disciplined OCXO with timecode and 1PPS
outputs. Our primary is a Datum/Symmetricom SSU2000 modular system with
a cesium PRS, a rubidium stratum 2E secondary clock, and an OCXO stratum
3E tertiary clock. The cesium PRS is down at the moment, but the
rubudium is close enough for current work.
The CentOS box runs very well for this purpose, and the interface wasn't
too difficult. I have not implemented the 1PPS discipline for the
kernel clock as yet, however, since the SSU2000 is up.
As far as cost is concerned, I would think CDMA, GSM, or LTE timecode
receivers would be a bit less expensive to integrate than GPS receivers,
but u-blox and others have really gotten the cost down for GPS modules.
GPS is already supported by the NTP server shipped with CentOS, where I
don't think any CDMA/GSM/LTE timecode receivers are (but I reserve the
right to be wrong!).
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] System Time Source
On 05/24/2017 11:29 AM, Pete Biggs wrote: ... The terrestrial radio clocks are actually not that accurate. They are not designed for keeping things like a system clock "correct". Commercial solutions only keep to within about +/- 0.5s per day, with resynchronisation happening about once a day. The GPS time system is also notoriously very precisely wrong. ... Whee, I had to check headers to see if my input filters had started pulling time-n...@febo.com traffic into my CentOS folder. and if you want to discuss the ins and outs of serious timekeeping, you might find that mailing list useful. (My $dayjob requires me to deal with that kind of precision.) No one has mentioned using the most ubiquitous of the time sync sources, though, and that's the digital cellular network. Any one of GSM, 4GLTE, or 3G or even old CDMA2000 works, and will have very precise time (it's required for the protocols for the phones to be locked to the base station's time, and most base stations use GPS or SONET timing signals and either disciplined OCXO's or rubidium standards frequency-locked to the GPS 1PPS or the SONET frame clock. Even a real T1 provided from the telco is traceable to a cesium PRS somewhere. ). One such standalone box is made by Beagle Software; see http://www.beaglesoft.com/celsynhome.htm and while it's not exactly cheap, the concept could be extended to use one of the commonly available SDR dongles (like an RTL-SDR) and the timecode could be retrieved with software. No cell account is required to receive the timecode. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SCSI drives and Centos 7
On 04/29/2017 09:50 AM, Gregory P. Ennis wrote: Has anyone used Centos 7 on SCSI drives, or am I going to need to get an upgrade of the server? The server is working great. I am, on IBM LS20 blades. The SCSI controller, according to lspci, is: 02:02.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 08) I'm not using it in RAID mode. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
