[CentOS] midco stealling searches, was browsers slowing Centos 7 installation to a crawl
On Mon, 5 Aug 2019, Michael Hennebry wrote: On Sun, 4 Aug 2019, John Pierce wrote: So you need to modify the source file that NetworkManager is using. somewhere in /etc/network or /etc/networking-scripts, a config file has DNS0=192.168.0.1 or sokmething, or your system is getting that from DHCP Will check on that. I've chacked on that. I've made what seemed like promissing changes to /etc/sysconfig/network-scripts/ifup-post and /etc/sysconfig/network-scripts/network-functions . No go. I still get the search line in resolv.conf . I've tried putting in search google.com , but on reboot, it still gives me midco and only midco . Any idea what does affect search in resolv.conf ? How can I fix this so I do not have to manually edit resolv.conf after each reboot. -- Michael henne...@web.cs.ndsu.nodak.edu "Sorry but your password must contain an uppercase letter, a number, a haiku, a gang sign, a heiroglyph, and the blood of a virgin." -- someeecards ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] SELinux is preventing 11-dhclient from add_name access on the directory chrony.servers.wlp8s0.
SELinux is preventing 11-dhclient from add_name access on the directory
chrony.servers.wlp8s0.
* Plugin catchall (100. confidence) suggests
**
If you believe that 11-dhclient should be allowed add_name access on the
chrony.servers.wlp8s0 directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c '11-dhclient' --raw | audit2allow -M my-11dhclient
# semodule -X 300 -i my-11dhclient.pp
Additional Information:
Source Contextsystem_u:system_r:NetworkManager_t:s0
Target Contextsystem_u:object_r:dhcpc_state_t:s0
Target Objectschrony.servers.wlp8s0 [ dir ]
Source11-dhclient
Source Path 11-dhclient
Port
Host castor
Source RPM Packages
Target RPM Packages
Policy RPMselinux-policy-3.14.4-40.fc31.noarch
Selinux Enabled True
Policy Type targeted
Enforcing ModeEnforcing
Host Name castor
Platform Linux castor 5.3.12-300.fc31.x86_64 #1 SMP
Thu Nov
21 22:52:07 UTC 2019 x86_64 x86_64
Alert Count 2
First Seen2019-11-30 18:03:35 CET
Last Seen 2019-12-01 11:16:46 CET
Local ID 0370e7fd-a826-4c80-8239-747a7528c5af
Raw Audit Messages
type=AVC msg=audit(1575195406.740:277): avc: denied { add_name } for
pid=1466 comm="11-dhclient" name="chrony.servers.wlp8s0"
scontext=system_u:system_r:NetworkManager_t:s0
tcontext=system_u:object_r:dhcpc_state_t:s0 tclass=dir permissive=0
Hash: 11-dhclient,NetworkManager_t,dhcpc_state_t,dir,add_name
--
Using Opera's mail client: http://www.opera.com/mail/
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 8 install of squirrelmail
On 2019-12-02 13:46, Earl Terwilliger via CentOS wrote: On 2019-12-02 13:15, Earl Terwilliger via CentOS wrote: Hi, I am trying to install Squirrelmail on Centos 8 but it seems that package is missing in the EPEL repo for Centos 8? Anyone know if this was on purpose or how to tell which packages won't be created? As far as I know, squirrelmail is noT actively maintained for quite some time: https://www.squirrelmail.org/ For this reason, variety of distributions phase it out, or may do it soon. Latest version coming as port on FreeBSD is dated Apr 4, 2018 (it runs under PHP-7.2 so I'm happy so far). I maintain two webmail front ends: squirrelmail and round cube. I plan to replace squirrelmail with Horde webmail soon. I hope, this helps. Valeri Thanks, Earl ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos -- Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos Thanks.. Squirrelmail is still available on Fedora 31 so I was thinking it still should be around for centos 8 (and it does work on the latest versions of php) I will have to look around for something to replace it but the big problem is getting the users to like something new... Horde webmail seems to be closest in appearance and interaction with user. Round cube is way different. I must confess though, I didn't have time to try horde webmail yet. Yes, and Fedora fully escaped my mind... so Fedora source package rebuilt on your system may be the smoothest solution. Valeri Earl ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos -- Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 8 install of squirrelmail
On 2019-12-02 13:36, Ulf Volmer wrote: On 02.12.19 20:15, Earl Terwilliger via CentOS wrote: I am trying to install Squirrelmail on Centos 8 but it seems that package is missing in the EPEL repo for Centos 8? Anyone know if this was on purpose or how to tell which packages won't be created? Squirrelmail is dead. Nobody did the work to port it to a recent php version. So I think you should switch to another webmail software. Roundcube is a good choice in my option, but there is also no package in EPEL 8. Thanks, that confirms my knowledge. FreeBSD port I have mentioned in my reply to OP's post does work with PHP 7.2. It could be port maintainer who made necessary patching. Anyway, as an interim solution while choosing what to migrate to it is possible to download tarball of FreeBSD port, and installed what is in it. It shouldn't be much trouble: php 7.2 it depends on is php 7.2 whatever system it is installed on. Just thought. Here is the link to FreeBSD port: https://www.freshports.org/mail/squirrelmail/ Here is reference to squirrelmail snapshots from the above: http://snapshots.squirrelmail.org/ I hope, this helps. Valeri Best regards Ulf ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos -- Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 8 install of squirrelmail
> > > On 2019-12-02 13:15, Earl Terwilliger via CentOS wrote: >> Hi, >> >> I am trying to install Squirrelmail on Centos 8 but it seems that >> package >> is missing in the EPEL repo for Centos 8? Anyone know if this was on >> purpose or how to tell which packages won't be created? > > As far as I know, squirrelmail is noT actively maintained for quite some > time: > > https://www.squirrelmail.org/ > > For this reason, variety of distributions phase it out, or may do it > soon. Latest version coming as port on FreeBSD is dated Apr 4, 2018 (it > runs under PHP-7.2 so I'm happy so far). I maintain two webmail front > ends: squirrelmail and round cube. I plan to replace squirrelmail with > Horde webmail soon. > > I hope, this helps. > > Valeri > >> >> Thanks, >> Earl >> ___ >> CentOS mailing list >> CentOS@centos.org >> https://lists.centos.org/mailman/listinfo/centos >> > > -- > > Valeri Galtsev > Sr System Administrator > Department of Astronomy and Astrophysics > Kavli Institute for Cosmological Physics > University of Chicago > Phone: 773-702-4247 > > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos > Thanks.. Squirrelmail is still available on Fedora 31 so I was thinking it still should be around for centos 8 (and it does work on the latest versions of php) I will have to look around for something to replace it but the big problem is getting the users to like something new... Earl ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 8 install of squirrelmail
On 2019-12-02 13:15, Earl Terwilliger via CentOS wrote: Hi, I am trying to install Squirrelmail on Centos 8 but it seems that package is missing in the EPEL repo for Centos 8? Anyone know if this was on purpose or how to tell which packages won't be created? As far as I know, squirrelmail is noT actively maintained for quite some time: https://www.squirrelmail.org/ For this reason, variety of distributions phase it out, or may do it soon. Latest version coming as port on FreeBSD is dated Apr 4, 2018 (it runs under PHP-7.2 so I'm happy so far). I maintain two webmail front ends: squirrelmail and round cube. I plan to replace squirrelmail with Horde webmail soon. I hope, this helps. Valeri Thanks, Earl ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos -- Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 8 install of squirrelmail
On 02.12.19 20:15, Earl Terwilliger via CentOS wrote: > I am trying to install Squirrelmail on Centos 8 but it seems that package > is missing in the EPEL repo for Centos 8? Anyone know if this was on > purpose or how to tell which packages won't be created? Squirrelmail is dead. Nobody did the work to port it to a recent php version. So I think you should switch to another webmail software. Roundcube is a good choice in my option, but there is also no package in EPEL 8. Best regards Ulf ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Centos 8 install of squirrelmail
Hi, I am trying to install Squirrelmail on Centos 8 but it seems that package is missing in the EPEL repo for Centos 8? Anyone know if this was on purpose or how to tell which packages won't be created? Thanks, Earl ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Adding kmod to pxe install
On 02/12/2019 16:08, Valeri Galtsev wrote: On 2019-12-02 10:00, Fabian Arrotin wrote: On 02/12/2019 12:42, Alexandre Leonenko wrote: Hey guys, I'm stumped in how to add the kmod rpm to pxe install. I need it to be installed but also loaded during the install as well. The rpm in question is the 3w-9xxx from elrepo https://centos.pkgs.org/8/elrepo-x86_64/kmod-3w-9xxx-2.26.02.014-1.el8_0.elrepo.x86_64.rpm.html I'm constantly getting the following message Warning: can't find installer main image path in .treeinfo Any help or pointing in right direction would be appreciated. Regards, Alex If you need it at install time, you need a dud (Driver Disk), so see http://mirrors.coreix.net/elrepo/dud/el8/x86_64/ and use inst.dd= Thank you, Fabian! I too may need it in close future. Valeri Hopefully it's obvious, but make sure you pick the driver update disk image that matches the kernel/point release you are installing (e.g, el8_0 or el8_1 etc). ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS-virt] Xen Version update policy
On 12/2/19 11:08 AM, Kevin Stange wrote: > On 11/28/19 12:12 PM, George Dunlap wrote: >> Hey all, >> >> This mail has been a long time in coming, but with the upcoming >> expiration of security support for Xen 4.8, it's time to start thinking >> about what our update policy will be for the Xen packages in general. >> >> Citrix is committed to officially supporting one Xen version at a time >> through the CentOS Virt SIG. (Others in the community are welcome to >> support others.) But we'd like input as to which version the community >> would like to be supported at any one time. >> >> Please express your opinion on each option by replying as follows: >> -2: This is a bad idea, and I would argue against this >> -1: I'm not happy with this, but I wouldn't argue against this. >> 0: No opinion. >> 1: I'm happy with this, but I wouldn't argue for it. >> 2: This is a great idea, and I'd argue for it. >> >> There are several possible options: >> >> 1. Always support the newest option. This means we get all the newest >> features from Xen in the Virt SIG by default; but also means we get all >> the newest bugs. >> >> 1a. Always support the newest option once it has at least one point >> release. This balances the newness with a bit of extra testing. >> >> 1b. Always support the second-to-newest version (e.g., when 4.13 comes >> out, switch to 4.12.x) >> >> 2. Always support the oldest security-supported version. This means we >> get the most stable version of Xen; but it does mean it is several years >> behind as far as features go. It also means that further bugfixes do >> not happen automatically, and further bugs found will need to be >> >> 3. Always support the oldest fully-supported version. Reasonably >> stable, reasonably old, still gets bugfixes. >> >> 4. Support a version until it's out of security support, then jump to >> the newest version. This minimizes the number of upgrades required >> (although may make each upgrade more painful). >> >> 4a. Support a version until it's out of full support, then jump to the >> newest version. >> >> Any other options? >> >> For my part, I think 1a, 1b, and 3 are all reasonable options. > > By supporting only even numbered releases as is the case now, it has not > been possible to do hot migration based upgrades which means that we > have to do full reboots of our entire environment every so often. Right > now we're running on Xen 4.8 and transitioning to 4.12 directly. We > skipped 4.10 because we felt that 4.12 has been out and stable for long > enough. Ideally if every major build of Xen were provided we would > transition by hot migrations up to the next release periodically and > stay on a security supported release each time one is going toward EOL. > > Personally I would love to see at the very least transitional packages > for each Xen version available to allow for easier hot migrations to the > latest release, under the assumption that such migrations are considered > "supported" upstream. I believe you said this was to be expected in a > previous conversation we had on IRC. > > I don't really think we should drop a release before its security > support ends, unless we have *really clear* communication to repo users > as to the life cycles of these builds in advance. > > I get why providing updates for 5 major releases concurrently is > prohibitive for the entire security support period, though if it were > more automated, maybe it would be easier to manage. > > I think the keys are making sure that the lifecycles are clearly > communicated in advance and that there's a fairly reliable path for > people to move up to the latest version that is suitable for production > use. So I wouldn't say no to a 1 + 1a + 1b configuration, with the idea > that 1 is effectively "testing" to become stable at 1a, then > simultaneously always provide 1b as well. That would, by my > interpretation mean there are always 2 or 3 supported versions. Right > now, 4.12 "stable" and 4.11 "legacy" would be supported. When 4.13 > comes out, 4.13 would be "testing" but would be fully maintained with > security and point release updates. When 4.13.1 is released it would > become "stable," 4.11 would be deprecated and 4.12 would become "legacy." > > However, during the transitional period maybe we need to commit to > supporting 4.10 until its security support ends. > I realized I didn't respond in any way to rate the options as requested. I don't really support any configuration that doesn't provide overlapping support for at least two versions simultaneously, so I've added my own options. Sorry! 1: -1 1a: -1 1b: -1 1 + 1a + 1b: +2 2: -1 3: -1 2 + 3: +1 4: -1 4a: -1 -- Kevin Stange Chief Technology Officer Steadfast | Managed Infrastructure, Datacenter and Cloud Services 800 S Wells, Suite 190 | Chicago, IL 60607 312.602.2689 X203 | Fax: 312.602.2688 ke...@steadfast.net | www.steadfast.net ___ CentOS-virt mailing
Re: [CentOS-virt] Xen Version update policy
On 11/28/19 12:12 PM, George Dunlap wrote: > Hey all, > > This mail has been a long time in coming, but with the upcoming > expiration of security support for Xen 4.8, it's time to start thinking > about what our update policy will be for the Xen packages in general. > > Citrix is committed to officially supporting one Xen version at a time > through the CentOS Virt SIG. (Others in the community are welcome to > support others.) But we'd like input as to which version the community > would like to be supported at any one time. > > Please express your opinion on each option by replying as follows: > -2: This is a bad idea, and I would argue against this > -1: I'm not happy with this, but I wouldn't argue against this. > 0: No opinion. > 1: I'm happy with this, but I wouldn't argue for it. > 2: This is a great idea, and I'd argue for it. > > There are several possible options: > > 1. Always support the newest option. This means we get all the newest > features from Xen in the Virt SIG by default; but also means we get all > the newest bugs. > > 1a. Always support the newest option once it has at least one point > release. This balances the newness with a bit of extra testing. > > 1b. Always support the second-to-newest version (e.g., when 4.13 comes > out, switch to 4.12.x) > > 2. Always support the oldest security-supported version. This means we > get the most stable version of Xen; but it does mean it is several years > behind as far as features go. It also means that further bugfixes do > not happen automatically, and further bugs found will need to be > > 3. Always support the oldest fully-supported version. Reasonably > stable, reasonably old, still gets bugfixes. > > 4. Support a version until it's out of security support, then jump to > the newest version. This minimizes the number of upgrades required > (although may make each upgrade more painful). > > 4a. Support a version until it's out of full support, then jump to the > newest version. > > Any other options? > > For my part, I think 1a, 1b, and 3 are all reasonable options. By supporting only even numbered releases as is the case now, it has not been possible to do hot migration based upgrades which means that we have to do full reboots of our entire environment every so often. Right now we're running on Xen 4.8 and transitioning to 4.12 directly. We skipped 4.10 because we felt that 4.12 has been out and stable for long enough. Ideally if every major build of Xen were provided we would transition by hot migrations up to the next release periodically and stay on a security supported release each time one is going toward EOL. Personally I would love to see at the very least transitional packages for each Xen version available to allow for easier hot migrations to the latest release, under the assumption that such migrations are considered "supported" upstream. I believe you said this was to be expected in a previous conversation we had on IRC. I don't really think we should drop a release before its security support ends, unless we have *really clear* communication to repo users as to the life cycles of these builds in advance. I get why providing updates for 5 major releases concurrently is prohibitive for the entire security support period, though if it were more automated, maybe it would be easier to manage. I think the keys are making sure that the lifecycles are clearly communicated in advance and that there's a fairly reliable path for people to move up to the latest version that is suitable for production use. So I wouldn't say no to a 1 + 1a + 1b configuration, with the idea that 1 is effectively "testing" to become stable at 1a, then simultaneously always provide 1b as well. That would, by my interpretation mean there are always 2 or 3 supported versions. Right now, 4.12 "stable" and 4.11 "legacy" would be supported. When 4.13 comes out, 4.13 would be "testing" but would be fully maintained with security and point release updates. When 4.13.1 is released it would become "stable," 4.11 would be deprecated and 4.12 would become "legacy." However, during the transitional period maybe we need to commit to supporting 4.10 until its security support ends. -- Kevin Stange Chief Technology Officer Steadfast | Managed Infrastructure, Datacenter and Cloud Services 800 S Wells, Suite 190 | Chicago, IL 60607 312.602.2689 X203 | Fax: 312.602.2688 ke...@steadfast.net | www.steadfast.net ___ CentOS-virt mailing list CentOS-virt@centos.org https://lists.centos.org/mailman/listinfo/centos-virt
[CentOS-docs] wiki.centos.org migration plan
Hi all, Almost all of you are probably aware, but I worked last week on a new ansible role to deploy/upgrade moin (what is used for wiki.centos.org) It's quite a "jump" from moin 1.5.3 to 1.9.10 (running on centos 7) The plan is to migrate the production instance maybe next week, and so let people on this list have a look at the moin parsers/syntax that will eventually have to be modified. The staging instance (migrated from wiki.centos.org snapshot last week) is available for you on https://wiki.stg.centos.org Worth knowing that the staging instance is *not* configured to send emails at this stage (so don't try the reset password feature as that will not work), as we wanted to avoid that moin instance sending mail on page edit operations to real subscribed people. PS : the old centos theme is gone, per discussion with Alain , who is working on some cosmetic changes on the theme you can see on the staging instance. Kind Regards, -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | twitter: @arrfab signature.asc Description: OpenPGP digital signature ___ CentOS-docs mailing list CentOS-docs@centos.org https://lists.centos.org/mailman/listinfo/centos-docs
Re: [CentOS] Adding kmod to pxe install
On 2019-12-02 10:00, Fabian Arrotin wrote: On 02/12/2019 12:42, Alexandre Leonenko wrote: Hey guys, I'm stumped in how to add the kmod rpm to pxe install. I need it to be installed but also loaded during the install as well. The rpm in question is the 3w-9xxx from elrepo https://centos.pkgs.org/8/elrepo-x86_64/kmod-3w-9xxx-2.26.02.014-1.el8_0.elrepo.x86_64.rpm.html I'm constantly getting the following message Warning: can't find installer main image path in .treeinfo Any help or pointing in right direction would be appreciated. Regards, Alex If you need it at install time, you need a dud (Driver Disk), so see http://mirrors.coreix.net/elrepo/dud/el8/x86_64/ and use inst.dd= Thank you, Fabian! I too may need it in close future. Valeri ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos -- Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Adding kmod to pxe install
On 02/12/2019 12:42, Alexandre Leonenko wrote: > Hey guys, > > I'm stumped in how to add the kmod rpm to pxe install. I need it to be > installed but also loaded during the install as well. > The rpm in question is the 3w-9xxx from elrepo > https://centos.pkgs.org/8/elrepo-x86_64/kmod-3w-9xxx-2.26.02.014-1.el8_0.elrepo.x86_64.rpm.html > > I'm constantly getting the following message > Warning: can't find installer main image path in .treeinfo > > Any help or pointing in right direction would be appreciated. > > Regards, > Alex If you need it at install time, you need a dud (Driver Disk), so see http://mirrors.coreix.net/elrepo/dud/el8/x86_64/ and use inst.dd= -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | twitter: @arrfab signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] update CentOS 7 at Nov 05 2019
the logs I have found where mentioned in the before message. I found the surprising time idendity between yum update and the stop of logging. All other logfiles seem OK. e.g. wtmp. rsyslog.conf is OK and same as in comparable servers. The time gap (some 2 weeks) between loss of log content and permanent rebooting of the server reminds me of virus behavior. Viele Grüße Helmut Drodofsky Internet XS Service GmbH Heßbrühlstraße 15 70565 Stuttgart Geschäftsführung Helmut Drodofsky HRB 21091 Stuttgart USt.ID: DE190582774 Fon: 0711 781941 0 Fax: 0711 781941 79 Mail: i...@internet-xs.de www.internet-xs.de Am 02.12.2019 um 00:58 schrieb Jonathan Billings: > On Dec 1, 2019, at 6:05 PM, Helmut Drodofsky wrote: >> any help to have kernel logging again? > > Have you done anything to resolve it? Restart rsyslog? Check the journal? > > -- > Jonathan Billings > > > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Adding kmod to pxe install
Hey guys, I'm stumped in how to add the kmod rpm to pxe install. I need it to be installed but also loaded during the install as well. The rpm in question is the 3w-9xxx from elrepo https://centos.pkgs.org/8/elrepo-x86_64/kmod-3w-9xxx-2.26.02.014-1.el8_0.elrepo.x86_64.rpm.html I'm constantly getting the following message Warning: can't find installer main image path in .treeinfo Any help or pointing in right direction would be appreciated. Regards, Alex ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
