unavailable SLU archives? and gom from epel-testing NOT WANTED!
Happy New Year! Back in ?Oct?Nov?Dec? was mention of SL7 clients not updating, running into ???libgtop (or was it something else) dependency fails. If I could find SLU archives, who said what when could be quoted, but ATM attempt to access SLU archives cycles a long time then ends up at blank page http://listserv.fnal.gov/archives/scientific-linux-users.html Can someone admin@SLU check the archives are available, link is ok (or not?) (It's what's on the SL "Community" page for "List Archives") The tail end of that thread was "enable the epel-testing repo = your SL7 client update will succeed" to which someone responded (paraphrased), "This works, but ... we are uneasy that for production SL7 systems, something from epel-testing is a dependency." (Implication with which we agree: nothing from epel-testing should be required on production system.) IIRC someone else replied something like "You could complain to epel about it" It's now much later & *STILL* this is not resolved. We don't want to install anything from epel-testing on our production system(s) but in the meantime updates are balking. We really like SL & want to rely on it for stable reliable production servers. Can anyone take action to resolve this issue? Many many thank you for SL, & for advice/pointers! PS Konstantin Olchanski's wry posts are HILARIOUS!! "instead of this obsolete email thing" yuk yuk yuk!
IPv6 DUID
Is there a file that contains, or command that will display, the DUID a system is using when communicating to a DHCPv6 server? I need to know what the DUID is so I can set a static reservation for the client but I've not been able to figure out the DUID for a given system until after it gets a dynamic address. -- Stephen Berg, IT Specialist, Oceanography Division, Code 7309 Naval Research Laboratory W: (228) 688-5738 DSN: (312) 823-5738 C: (228) 365-0162
Re: unavailable SLU archives? and gom from epel-testing NOT WANTED!
On 01/04/2019 03:27 AM, Winnie Lacesso wrote: Happy New Year! Back in ?Oct?Nov?Dec? was mention of SL7 clients not updating, running into ???libgtop (or was it something else) dependency fails. If I could find SLU archives, who said what when could be quoted, but ATM attempt to access SLU archives cycles a long time then ends up at blank page http://listserv.fnal.gov/archives/scientific-linux-users.html Can someone admin@SLU check the archives are available, link is ok (or not?) (It's what's on the SL "Community" page for "List Archives") I'm not an admin, but can confirm it does not load from here either... The tail end of that thread was "enable the epel-testing repo = your SL7 client update will succeed" to which someone responded (paraphrased), "This works, but ... we are uneasy that for production SL7 systems, something from epel-testing is a dependency." (Implication with which we agree: nothing from epel-testing should be required on production system.) IIRC someone else replied something like "You could complain to epel about it" This was on November 26th, since I have a bad habit of not deleting emails. I can forward them to you off-list if you would like copies before the list archive is repaired. It's now much later & *STILL* this is not resolved. We don't want to install anything from epel-testing on our production system(s) but in the meantime updates are balking. We really like SL & want to rely on it for stable reliable production servers. Can anyone take action to resolve this issue? This is technically a problem with the EPEL people and should be handled through their channels. It does not appear to be an issue with any of the core SL packages. You can try their IRC channel, emailing lists, or RedHat's bugzilla "Fedora EPEL" designation. https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_EPEL-23Communicating-5Fwith-5Fthe-5FEPEL-5FSIG&d=DwICaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=SNMKuRMPfmtX7rMdiTai-NKnQzmU0HExVmiMISQg1lg&s=tu2PjNKsk0IyPgvQdyaGecz-g6MRDG7NC0T6IhmBq4w&e= I believe there is at least 1 EPEL contributor who also subscribes to the SL lists who may see this as well.
Re: unavailable SLU archives? and gom from epel-testing NOT WANTED!
Thanks for the report. The listserv site is working over https: https://listserv.fnal.gov/archives/scientific-linux-users.html I'm pretty sure there should be a redirect there. Inquiring with the listserv admins. I've updated the links on the SL site to point to https in the meantime. On 1/4/19 8:08 AM, Mark Stodola wrote: >> http://listserv.fnal.gov/archives/scientific-linux-users.html >> >> Can someone admin@SLU check the archives are available, link is ok (or >> not?) (It's what's on the SL "Community" page for "List Archives") >> > > I'm not an admin, but can confirm it does not load from here either... -- Bonnie King
Re: IPv6 DUID
On Fri, Jan 4, 2019 at 2:44 PM Stephen Berg (Code 7309) <08e536c5aab1-dmarc-requ...@listserv.fnal.gov> wrote: > > Is there a file that contains, or command that will display, the DUID a > system is using when communicating to a DHCPv6 server? I need to know > what the DUID is so I can set a static reservation for the client but > I've not been able to figure out the DUID for a given system until after > it gets a dynamic address. I don't use dhcp or ipv6 but wouldn't the DUID be in the lease file, under "/var/lib/dhcp/" or "/var/lib/dhclient/"?
