Re: IBM to buy Red Hat for $34B
Cant say. Most likely it wont for next year or so. But on its own, i think, really bad for RH line of linux.. On Sun, Oct 28, 2018, 20:33 Adam Jensen wrote: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__techcrunch.com_2018_10_28_ibm-2Dto-2Dbuy-2Dred-2Dhat-2Dfor-2D34b-2Din-2Dcash-2Dand-2Ddebt-2Dtaking-2Da-2Dbigger-2Dleap-2Dinto-2Dhybrid-2Dcloud_=DwICaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=dDZ1LjYOSDggiULMOXXrP7DeNGliGZPcR8KvIznvVVs=tuIZ7q6CdYDvVD13KSer-11q1DVlK3I9w1TmC4wIr_s= > > Will this affect Scientific Linux? >
Re: Config file for SL7.5 in mock
On Fri, Oct 26, 2018 at 10:08 AM John Pilkington wrote: > > I have successfully used mock in Fedora 27 and Fedora 28 to build rpms > to run under Scientific Linux (as well as ones to run natively.) > > At first I used a locally written config file, but more recently > /etc/mock/epel-7-x86_64-rpmfusion-free.cfg has worked. > > It is based on /etc/mock/epel-7.cfg, which is also installed in SL, but > refers to, and uses, the centos repos. Are conflicts likely? Is there > an SL version? I've dealt with exactly this for RHEL, CentOS, and SL compatibily in the past. Please feel free to examine the kind of work I've done to use local "mock" config files in local working directories, with my work with Samba, py2pack, and other tools. The py2pack is probably the smallest and the easy to read, and most recently tested, at https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_nkadel_py2packrepo_=DwIBaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=e8QE3bNpzYFsoB87nXmh_AnW6tOeek_DvXYX7A4gGwk=FiZhMu9KeA3Z2Zrtkz3v4CG7swzrDLe6oCq83tuDBY0= Also, if you need to use SL, I'd encourage you to set up a local mirror of SL, even on your local system so you can use "file:///" based URLs for your repositories. My local mirroring scripts are at https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_nkadel_nkadel-2Drsync-2Dscripts=DwIBaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=e8QE3bNpzYFsoB87nXmh_AnW6tOeek_DvXYX7A4gGwk=-ROe2I5upw-eHD6B25OCusqTHwcjfBsbSiPN9RH8aWg=
Re: boot hang
On 10/28/18 2:24 AM, Yasha Karant wrote: On 10/27/2018 07:08 PM, Orion Poplawski wrote: On 10/27/18 10:42 AM, Yasha Karant wrote: Using yumex, rather than doing a full update to SL 7.5 production, I attempted to update over the network the kernel, firmware, and libgcc, allowing yumex (essentially yum) to establish the needed dependencies (other applications, etc., that also needed to be updated). The resulting kernel will not boot, but merely hangs. If one waits long enough, the "progress bar" at the bottom of the screen does show the typical blue/white progression, but that is all. When I reboot and manually select the previous kernel, the system reboots. I am using MATE for a "control" GUI, although as the system never gets to the login screen, MATE should not be "active". It appears that yumex (yum) does not fully resolve all required dependencies. What other components must I update? Pressing should get you the text boot messages which hopefully should point you towards what is going wrong - or remove rhgb from the kernel command line. Following your suggestion, I pressed . Ultimately, the boot hung at "Waiting for Plymouth boot screen to quit ..." Was something misconfigured/misinstalled by the yumex update of the kernel? I did note from the text messages that "Starting Gnome Display Manager" appeared at multiple steps. Looks like the X server is failing to start for some reason. You should be able to ssh into the machine or do ctrl-alt-f2 to get a text login window. Take a look at /var/log/Xorg.0.log, etc. If you are using nVidia drivers that's a likely suspect for what went wrong. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://urldefense.proofpoint.com/v2/url?u=http-3A__www.nwra.com=DwIDaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=PF4o0on_WU-cHiG8c5Gf6osaJ_-wxzyiPo49FwQveM4=U-PyiVrUzCKJsLnD7vw9vjPStB9bT8KXGA5DQ4ugB7w=
Re: Bind Scientific Linux to AD
Thank you Bruce and Nico. Nico I will try to use the auto-config tools and auto mounts again on my test VM. Best, Adil Sent from my iPhone > On Oct 28, 2018, at 7:50 AM, Nico Kadel-Garcia wrote: > >> On Fri, Oct 26, 2018 at 10:18 AM Alvi, Adil H wrote: >> >> >> Good Morning, >> >> >> I was trying to bind a workstation running SL 6.5 to AD, so that users can >> login with their AD accounts, and mount a Windows File Share Server binded >> to AD. > > Stop here. You should update to the latest version of SL 6 if you're > going to continue to use it. > > Second. AD registration can be done many different ways, but > installing "/usr/bin/net" and using the "net ads" command from Samba > to register it works well. You can spend more time with "authconfig" > and "realmd" and other tools, but I find the /usr/bin/net tool to work > well. > > Third: mounting anything normally requires root privileges. If the > mount points are well defined, and you're willing to store credentials > on the Linux server, you can sidestep this and use automount in in > /etc/auto.master and /etc/auto.cifs to store credeitnals and enable > well-defined specific mounts in advance. The "oddjob" tool mentioned > by Bruce Ferrell may work well, I've not used it since I wanted stable > mounts. > > Fourth: activating an AD connection requires at least Kerberos client > setups, with "net ads" can do or the "authconfig" tool, and does > require good time synchronization with the AD server. Most NTP sestups > can do this well, but check for time drift on the AD server and your > local host. > > The rest depends on details, like whether you have enough privilege to > actually register the host with tools like "net ads" or "realmd", or > whether you need to simply activate an LDAP "bind" account with > read-only access to LDAP to make things work. > >> After spending a week, I gave up. Steps, links/resources to bind SL will be >> greatly appreciated. >> >> >> Best Regards, >> Adil >> >>
Re: Bind Scientific Linux to AD
On Fri, Oct 26, 2018 at 10:18 AM Alvi, Adil H wrote: > > > Good Morning, > > > I was trying to bind a workstation running SL 6.5 to AD, so that users can > login with their AD accounts, and mount a Windows File Share Server binded to > AD. Stop here. You should update to the latest version of SL 6 if you're going to continue to use it. Second. AD registration can be done many different ways, but installing "/usr/bin/net" and using the "net ads" command from Samba to register it works well. You can spend more time with "authconfig" and "realmd" and other tools, but I find the /usr/bin/net tool to work well. Third: mounting anything normally requires root privileges. If the mount points are well defined, and you're willing to store credentials on the Linux server, you can sidestep this and use automount in in /etc/auto.master and /etc/auto.cifs to store credeitnals and enable well-defined specific mounts in advance. The "oddjob" tool mentioned by Bruce Ferrell may work well, I've not used it since I wanted stable mounts. Fourth: activating an AD connection requires at least Kerberos client setups, with "net ads" can do or the "authconfig" tool, and does require good time synchronization with the AD server. Most NTP sestups can do this well, but check for time drift on the AD server and your local host. The rest depends on details, like whether you have enough privilege to actually register the host with tools like "net ads" or "realmd", or whether you need to simply activate an LDAP "bind" account with read-only access to LDAP to make things work. > After spending a week, I gave up. Steps, links/resources to bind SL will be > greatly appreciated. > > > Best Regards, > Adil > >
Re: boot hang
On 27/10/18 17:42, Yasha Karant wrote: Using yumex, rather than doing a full update to SL 7.5 production, I attempted to update over the network the kernel, firmware, and libgcc, allowing yumex (essentially yum) to establish the needed dependencies (other applications, etc., that also needed to be updated). The resulting kernel will not boot, but merely hangs. If one waits long enough, the "progress bar" at the bottom of the screen does show the typical blue/white progression, but that is all. When I reboot and manually select the previous kernel, the system reboots. I am using MATE for a "control" GUI, although as the system never gets to the login screen, MATE should not be "active". It appears that yumex (yum) does not fully resolve all required dependencies. What other components must I update? At one time, SL (EL) allowed one to do an update from local media during the boot from local installation media (e.g., a USB stick flash drive) -- this no longer directly is supported. As I do not have the time to extract from the previous source how this was accomplished, and have not found a script (or GUI version thereof) that accomplishes the same task, I attempted a minimal update using yumex. Yasha Karant Re-sending, with addition, to list: I don't have your constraints on web access, but I have no current issues with yumex. There was some strangeness earlier in 7x upgrades that may now have been fixed. See the list archives, 2018 May 15 https://listserv.fnal.gov/scripts/wa.exe?A2=ind1805=SCIENTIFIC-LINUX-USERS===13374 or https://listserv.fnal.gov/scripts/wa.exe?A1=ind1805=SCIENTIFIC-LINUX-USERS#15 And have you tried yumex again under the old kernel? I don't know what video card you are using; is it nvidia? Have you enabled rpmfusion-nonfree-updates (or some other repo with nvidia drivers?) John P
Re: boot hang
On 10/27/2018 07:08 PM, Orion Poplawski wrote: > On 10/27/18 10:42 AM, Yasha Karant wrote: >> Using yumex, rather than doing a full update to SL 7.5 production, I >> attempted to update over the network the kernel, firmware, and libgcc, >> allowing yumex (essentially yum) to establish the needed dependencies >> (other applications, etc., that also needed to be updated). The >> resulting kernel will not boot, but merely hangs. If one waits long >> enough, the "progress bar" at the bottom of the screen does show the >> typical blue/white progression, but that is all. When I reboot and >> manually select the previous kernel, the system reboots. I am using >> MATE for a "control" GUI, although as the system never gets to the login >> screen, MATE should not be "active". It appears that yumex (yum) does >> not fully resolve all required dependencies. What other components must >> I update? > > Pressing should get you the text boot messages which hopefully > should point you towards what is going wrong - or remove rhgb from the > kernel command line. > > Following your suggestion, I pressed . Ultimately, the boot hung at "Waiting for Plymouth boot screen to quit ..." Was something misconfigured/misinstalled by the yumex update of the kernel? I did note from the text messages that "Starting Gnome Display Manager" appeared at multiple steps.
