Re: [CentOS] USB Serial Ports

[Denniston, Todd A CIV NAVSURFWARCENDIV Crane, JXVS]

> -Original Message-
> From: Chris Olson [mailto:chris_e_ol...@yahoo.com]
> Sent: Thursday, November 16, 2017 5:42 PM
> To: CentOS Mailing List
> Subject: [CentOS] USB Serial Ports
> 
> We have several CentOS 6 systems that are used in various configurations
> of test equipment.  One of the primary functions of these systems is the
> connectivity to serial ports of some operational systems that have serial
> port control requirements.  Lack of interface bus slots led us to the use
> of USB connected serial ports on these CentOS 6 systems.
> 
> We first used these USB connected serial ports in our RHEL 5 test equipment
> systems.  With RHEL 5, shut down and boot up of the systems would often
> cause the serial ports to have a different driver name, even though we had
> not changed the ports where the USB devices were plugged in.  This caused
> software access problems until we discovered what could be done using the
> udev rules to lock in the driver names.
> 
> This problem seems to have gone away in our newer systems with CentOS 6,
> and we would like to make sure that it does not return.  We are deploying
> some of the systems and do not want to have software access issues in the
> field where fixes are more difficult.  We would like to know if there is
> some underlying factor that has solved this problem for us.  Any ideas on
> what to check would be greatly appreciated.
> 
I have no idea why it is working better under 6, but it is possible to use UDEV 
rules to force them to be at expected /dev/my_tty* locations using 
vendor_ID/device_ID/serial_number combinations.  Once you figure that out, you 
should even be able to use the same (or at least similar) rules under 7.

--
Even when this disclaimer is not here:
I am not a contracting officer. I do not have authority to make or modify the 
terms of any contract.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] How to blacklist a device driver (sysemd)

[Denniston, Todd A CIV NAVSURFWARCENDIV Crane, JXVS]

> -Original Message-
> From: James Pearson [mailto:jame...@moving-picture.com]
> Sent: Friday, November 17, 2017 5:21 AM
> To: CentOS mailing list; Frank Thommen
> Subject: Re: [CentOS] How to blacklist a device driver (sysemd)
> 
> Frank Thommen wrote:
> > Hi,
> >
> > how can a specific device driver in CentOS 7 be blacklisted, so that it
> > doesn't load at boot time?  We have Infiniband adapters which are not
> > completely supported by CentOS and we want to silence the error messages
> > for the time being.
> >
> > I tried with the files
> >
> >    /etc/modprobe.d/blacklist
> >    /etc/modprobe.d/blacklist.conf

> >
> > None of these entries helps.  mlx5_core and mlx5_ib are still loaded and
> > the system is flooded with error messages.
> 
> They are probably being loaded via the initramfs at boot time - i.e.
> before the real root is mounted (where the blacklist entries exist)
> 

Having had to blacklist things like this in the past, it has been my experience 
that James is correct.
If the driver is available in the existing initrd (created before the updates 
to the blacklists), then the driver WILL be loaded prior to the blacklists 
being read.
For me I found two solutions that worked:
1) (re)install a new kernel after blacklist creation (which causes an dracut 
run with all the correct parameters)
2) create the blacklists, then workout the correct dracut parameters and run it.

obviously from the point of avoiding research time, doing a boot into an 
_older_ kernel, 
'yum remove kernel-currentversion; yum update kernel' is easier, but once you 
figure out how to tell Dracut to use it's usual parameters for each machine you 
can avoid the time of doing the extra reboot on a bunch of machines.  It has 
been ~4 years since I looked at this so I don't remember how to automate using 
the right options per machine.
Or you could wait for the next CentOS 7 kernel update...Unfortunately the CVE's 
for the 6 kernel that just came out were all fixed in the 7 kernel back in 
October, so I have no expectation of a new 7 kernel anytime soon.

--
Even when this disclaimer is not here:
I am not a contracting officer. I do not have authority to make or modify the 
terms of any contract.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] home on nfs

[Denniston, Todd A CIV NAVSURFWARCENDIV Crane, JXVS]

> -Original Message-
> From: hw [mailto:h...@adminart.net]
> Sent: Monday, October 30, 2017 12:02 PM
> To: CentOS mailing list
> Subject: Re: [CentOS] home on nfs
> 
> Jonathan Billings  writes:
> 
> > On Oct 28, 2017, at 23:15, hw  wrote:
> >>
> >> Jonathan Billings  writes:
> >>
>  On Oct 27, 2017, at 10:21, hw  wrote:
> 
>  Hi,
> 
>  I have the home directory of a user on an nfs server and mount it on a
>  client.  When the user logs in, they end up in the root directory rather
>  than in their actual home directory and need to cd into it.
> 
>  The user can read and write to their home directory, so it kinda works
>  fine --- but only kinda.  When the user starts emacs, some of the
>  settings in ~/.emacs are not applied, but the saved desktop is being
>  loaded.
> 
>  Both machines are running Centos 7.4.  What could be wrong with the nfs
>  mount?
> >>>
> >>> Sounds like you haven’t set the selinux Boolean for NFS homedirs.
> >>> setsebool -P use_nfs_home_dirs 1
> >>
> >> Oh, indeed, I didn´t know that I need to do that.
> >>
> >> Do I do this on the client or on the server or both?
> >
> > Just the client.
> 
> Thanks, I tried that and it works now :)
> 

If you find that the problem comes back in the near future (or perhaps check as 
a preventative), you should look to see if the client machine is using the 
'soft' mount option instead of 'hard,intr' on the home dirs.  A few years ago 
it took me better than a month to figure out that some other admin had (on some 
machines) thought that using soft would cause less waiting on reboots, but we 
found that the side effect on home directories was corrupt data and strange 
issues on user login. (soft can work OK if there is a longish timeout between 
mount request and mount use, but if it is quick like autofs at login, then soft 
falls down.)

--
Even when this disclaimer is not here:
I am not a contracting officer. I do not have authority to make or modify the 
terms of any contract.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] TeX Live on CentOS 7

[Denniston, Todd A CIV NAVSURFWARCENDIV Crane, JXVS]

> -Original Message-
> From: Nicolas Kovacs [mailto:i...@microlinux.fr]
> Sent: Friday, July 21, 2017 2:29 AM
> To: CentOS
> Subject: [CentOS] TeX Live on CentOS 7
> 
> Hi,
> 
> I just installed the OpenVAS vulnerability scanner on my CentOS 7
> workstation. Everything seems to work fine, except PDF generation. The
> 'openvas-check-setup' script tells me that PDF generation works fine,
> but whenever I want to generate a report, the result is unusable and
> can't open in Evince or Okular.
> 
> After googling a bit, I found out that several users complained that Tex
> Live is broken under RHEL/CentOS 7.
> 
> While I did use LaTeX a long time ago to write documents, I don't use it
> anymore nowadays (just Markdown or LibreOffice). But I do need a working
> installation of TeX Live for OpenVAS PDF reports.
> 
> What can I do now? Perform a manual installation of TeX Live with their
> provided installer (to /opt) and then blacklist all texlive* packages? I
> admit I'm a bit surprised that a distribution like RHEL/CentOS that
> prises quality wouldn't provide a working TeX Live in their package
> repositories.
> 
> Any suggestions?

The users that were complaining, were they all OpenVAS user?

Going from my experiences on CentOS 6, I find it surprising that LaTeX is not 
working.
Does even the trivial.tex from [0] compile?
Can you get the LaTeX file that OpenVAS is generating, and on the command line 
run pdflatex (or other latex compile command) on it and capture the error 
messages?
This might point to missing packages/fonts.

It may be possible that not enough of texlive has been installed.   I tend to 
do a `yum install \*latex\*` (and answer no) to see what is available and then 
install every latex thing that is not a -devel package. That way I never have 
to think about getting packages again, or if I do I will pretty much know I'll 
have to get it from CTAN myself.
seeing [1] from the opanvas wiki makes me think you should try `yum install 
\*latex\*extra\*` and see if it is now available.  And as seen elsewhere [2] 
sometimes rpm packager's don't name them the same as LaTeX packagers.   And it 
looks like[3] a lot of folks take the same 'trash the distro' perspective as 
openvas[1] which is unfortunate.  Perhaps we could ask the CentOS-extras (and a 
RHEL or EPEL ticket) folks if they would be willing to rebuild the needed 
packages from an old Fedora RPM if they are not yet available in a EL 
repository.  Have you checked EPEL?


[0] https://www.centos.org/forums/viewtopic.php?t=48421
[1] https://wiki.openvas.org/index.php/Generate_a_PDF_report#CentOS_7
[2] https://tex.stackexchange.com/a/166140
[3] https://www.centos.org/forums/viewtopic.php?t=54410

--
Even when this disclaimer is not here:
I am not a contracting officer. I do not have authority to make or modify the 
terms of any contract.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] What besides Postfix should not start until system time set?

[Denniston, Todd A CIV NAVSURFWARCENDIV Crane, JXVS]

From: Robert Moskowitz [r...@htt-consult.com]
Sent: Thursday, April 20, 2017 5:00 PM
To: CentOS mailing list
Subject: [CentOS] What besides Postfix should not start until system time   
set?
> 
> So I have learned that Postfix should delay until Chronyd has moved the
> system time from 0 to current.

Something you might consider to make the time delta _less_ drastic, is to 
create a service which on system shutdown touches a file {in /etc/} and on boot 
early in the start-up {make some other services depend on it} checks to see if 
the system date is before the time on that file, if it is then use the 
time stamp {+ a few sec} on the file to set the current time.  That way time 
would at least move forward.

in the olden days we used to use `hwclock --badyear` mitigate part of it. 
perhaps you could extend hwclock for --dead-batteries and make it easier for 
every one  with an arm {assuming hwclock is still used in the boot process to 
pull the initial time from the clock}. :)

Even when this disclaimer is not here:
I am not a contracting officer. I do not have authority to make or modify the 
terms of any contract.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Compiling custom "vmlinuz" PXE kernel?

[Denniston, Todd A CIV NAVSURFWARCENDIV Crane, JXVS]

> From: Locane [loc...@gmail.com]
> Sent: Monday, April 03, 2017 8:33 PM
> To: CentOS mailing list
> Subject: [CentOS] Compiling custom "vmlinuz" PXE kernel?
> 
> Hello CentOS list, I still need help.
> 
> Does anyone know how I would go about creating my own "vmlinuz" PXE
> kernel?  I'm still trying to get the NUC6CAYH to load to a LiveCD, and I'm
> getitng nowhere with Intel.
> 
> My company wants to do hundreds of these per month;  we're not above paying
> for professional help at this point.
> 
> My current line of reasoning is to get whatever specialized memory and CPU
> drivers the NUC6CAYH requires to recognize properly and bake them in to a
> custom vmlinuz PXE kernel that loads the initial ramdisk image.  This
> kernel is located in a regular CentOS 7.3 DVD at
> CentOS-7-x86_64-DVD-1611/images/pxeboot/vmlinuz.
> 
> Has anyone done this before?  Is there documentation online?

If I understand correctly you are wanting to build a kernel to boot the install 
process with, i.e., boot to run anaconda.
For some reason I never had any luck [with EL4] replacing the modules in the 
anaconda initrd.img with the ones for the kernel I built, so I took a more 
*brittle* path.
I built a kernel that included *_all_* the drivers I needed (and only those 
*_needed_*) built into the kernel itself, i.e., *not* as modules.  I then set 
the process up to boot from the vmlinuz I built.  It was not right to ignore 
the mods in the initrd, but it worked enough to get us going, IIRC it was 
because some USB driver we needed was not built in and we were installing from 
a USB hard drive.
Also note, you need to grab the kernel config for an EL kernel of your distro 
and start modifying from there because some of the later tools in the install 
chain expect most of the kernel to be configured as RH would do it.


*_all_* - using this method you can't depend on ANY modules, everything you 
need to activate all the hardware in the system has to be in the kernel image 
(vmlinuz).  If you can figure out how to correctly mod the initrd then you can 
use some modules again, and then only the modules you need to boot and read the 
initrd have to be in vmlinuz.  Also I don't recall what they are, but there are 
some size limits to how big vmlinuz can be, so don't just build every driver 
into the kernel.

Good luck.
--
Even when this disclaimer is not here:
I am not a contracting officer. I do not have authority to make or modify the 
terms of any contract.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Nvidia related kernel panic on boot, *unless* the keyboard is tapped

[Denniston, Todd A CIV NAVSURFWARCENDIV Crane, JXVS]

> -Original Message-
> From: Duncan Brown [mailto:cent...@duncb.co.uk]
> Sent: Wednesday, March 01, 2017 5:49 AM
> To: CentOS@centos.org
> Subject: [CentOS] Nvidia related kernel panic on boot, *unless* the keyboard 
> is tapped
> 
> So here is an odd one
> 
> Ever since the upgrade to 7.3, when using the el-repo kmod-nvidia, boot
> hangs around the 'mounted /boot' point. If left it then kernel panics
> 
> However at that point, tapping the keyboard gets it going again. As I'm
> using a wireless keyboard, even the act of switching the keyboard on
> gets it going again
> 
> This doesn't happen without the kmod, and I'm in the process of
> capturing the panic to file the bug report with el-repo, but for the
> sake of conversation has anyone seen anything like this before, or have
> any idea why that could happen?
> 
> cheers
> 
> Dunc
> 

I have not checked to see if elrepo has kicked out all the new drivers to fix 
it since then, but apparently RH changed some kernel 'pointers' in 7.3 which 
kind of messes up some of the kmods:
https://elrepo.org/bugs/view.php?id=715
https://elrepo.org/bugs/view.php?id=710

I am betting that you installed the kmod-nvidia before the upgrade to 7.3 and 
thus did not get the kind of warning that those folks did.
Perhaps even related to this issue:
https://elrepo.org/bugs/view.php?id=693

which kmod-nvidia do you have?  At the bottom of 693, pperry indicates: 
"kmod-nvidia-367.57-2.el7.elrepo.x86_64 is for EL7.3".

Even when this disclaimer is not here:
I am not a contracting officer. I do not have authority to make or modify the 
terms of any contract.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 6, firefox, PIV cards

[Denniston, Todd A CIV NAVSURFWARCENDIV Crane, JXVS]

m.roth at 5-cent.us further wrote:
##
m.roth at 5-cent.us wrote:
> Hi, folks,
>
>Up until a few weeks ago, it worked as it has been for years: firefox,
> security device is libcoolkey, and pcscd.
>
>Today, I go to use it (I have done updates sine I last used it), and
> try preferences->advanced->certificates, and it hangs. My most recent
> try was for over 20 min. If you move something over the window, then
> move it away, it's a blank window. Pull out the card, and *some* of the
> time, it pops up the window showing no certs, having never asked for a
> PIN. The rest of the time, firefox crashes, hard.
>
>I know the pcscd part works - I used it via a script this morning from
> the command line, as does pkcs15-tool from the command line.
>
>Anyone got any clues? Maybe I should downgrade (if I can) firefox?
>
Additional info: I tried bringing up firefox with two other profiles. One
didn't have coolkey as a security device, but when I tried to add it, it
responded with "cannot add module".

Yet a third profile, that had both libcoolky and the older onepin, and
that popped up a window saying I needed to authenticate, sat there with no
way to put a pin in, then, when I pulled the card, it flashed the popup
window with my certs.

Yes, at this time, I'm looking at issues with firefox.

So - has anyone else had this problem?

   mark
#

Not yet had the issue(s) but I do have some questions:
1) is this with the same physical PIV that you have been using "Up until a few 
weeks ago", that is did you (or the affected person) get a new PIV recently?
1a) does firefox have the certificate authorities loaded which cover the card 
in question (make sure to trace back to the root CA, there have been changes)?

2) have you tried just `yum downgrade firefox` and see if it works?
2a) I would be tempted to do something on the order of `rpm -qa --last |head 
-50` and then for each package seen there do an rpm -q --verify (syntax unsure) 
on them to be sure all the packages got installed correctly.

3) same as (2) but with recent nss|coolkey|pcscd updates?

4) interrupted updates?  i.e., `yum complete-transaction` (sp???)  `yum 
reinstall firefox nss coolkey pcscd`

Even when this disclaimer is not here:
I am not a contracting officer. I do not have authority to make or modify the 
terms of any contract.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos