Re: SL6 firefox issue.

[Alan Bartlett]

On 18 July 2018 at 17:37, Jesse Bren  wrote:
> Thank all, this is very useful.
>
> Does anyone know - should an update or fix be expected from upstream or
> otherwise?
>
An update has just been released upstream.

[Duo2 tmp]$ rpm -q firefox
firefox-60.1.0-6.el6.x86_64
[Duo2 tmp]$ rpm -q --changelog firefox | head -n 17
* Mon Jul 09 2018 Jan Horak  - 60.1.0-6
- Fix for missing schemes for bundled gtk3

* Mon Jun 25 2018 Martin Stransky  - 60.1.0-5
- Added mesa-libEGL dependency to gtk3/rhel6

* Sun Jun 24 2018 Martin Stransky  - 60.1.0-4
- Disabled jemalloc on all second arches

* Fri Jun 22 2018 Martin Stransky  - 60.1.0-3
- Updated to 60.1.0 ESR build2

* Thu Jun 21 2018 Martin Stransky  - 60.1.0-2
- Disabled jemalloc on second arches

* Wed Jun 20 2018 Martin Stransky  - 60.1.0-1
- Updated to 60.1.0 ESR
[Duo2 tmp]$

Alan.

Re: We're into weird and wonderful land... The g_ether kernel module

[Alan Bartlett]

On 21 January 2018 at 00:08, Bruce Ferrell <bferr...@baywinds.org> wrote:
> On 1/20/18 3:42 PM, Alan Bartlett wrote:
>
> I'll suggest that you try something like the following --
>
> $ lsusb > unconnected.txt
> Plug in the device.
> $ lsusb > connected.txt
> $ diff unconnected.txt connected.txt
>
> -- and then report the hexadecimal ID pairing. From that, we might be
> able to deduce the required driver.
>
> Here's my real-life example --
>
> [Duo2 tmp]$ lsusb > unconnected.txt
> [Duo2 tmp]$ # Plugged in the device.
> [Duo2 tmp]$ lsusb > connected.txt
> [Duo2 tmp]$ diff connected.txt unconnected.txt
> 1d0
> < Bus 002 Device 002: ID 0b95:7720 ASIX Electronics Corp. AX88772
> [Duo2 tmp]$
>
> -- the hexadecimal ID pairing for my example being 0b95:7720. That ID
> pairing points to the asix driver.
>
> Alan.
>
> Thanks loads Alan,
>
> The "gadget" I'm plugging is, is a Raspberry PI and I found that the
> Scientific side is doing the right thing.  ifconfig usb0 shows the usb
> network interface appears as it's supposed to.  udev works!
>
> I stupidly thought I had to load g_ether on the "host" side.  No... Not
> really.  Just on the PI and that works out of the box.
>
> We can all go back to sleep now.
>
> I've been down the rabbit hole, learned how to build a modified kernel,
> found out that wasn't what I needed after all  and returned to what I
> started out to do... a PI cluster using USB networking.
>
>
Thanks for the update. I'm pleased to know things are working correctly.

A Pi Cluster using USB networking reads as "interesting". Perhaps you
will write it up somewhere, when time permits?

Alan.

Re: We're into weird and wonderful land... The g_ether kernel module

[Alan Bartlett]

On 19 January 2018 at 22:32, Bruce Ferrell  wrote:
>
>
> On 1/19/18 12:41 PM, Akemi Yagi wrote:
>
> On Fri, Jan 19, 2018 at 10:31 AM, Bruce Ferrell 
> wrote:
>
> On 1/18/18 3:51 PM, Bruce Ferrell wrote:
> On 01/18/2018 05:58 AM, Mark Stodola wrote:
>
> I just checked a vanilla kernel source tree against the kernel source rpm...
> ./drivers/usb/gadget is empty in the rpm version!
>
> What's up with that?
>
> usb-gadget is not supported upstream by TUV
>
> You could try the alternate kernels from ELrepo perhaps.
> -Mark
>
> Next on my agenda... I was just startled to see part of the source tree
> stripped out.
>
> ...And I find what looked like was stripped out is an artifact of not having
> the module enabled
>
> That's what I get for not building kernels since to early 2000s
>
> All of that aside, were one to WANT to rebuild the kernel, how would one go
> about that?
>
> As suggested by Mark, you can try ELRepo's kernel-ml or kernel-lt. In
> both kernels, gadget is enabled in the config:
>
> CONFIG_USB_GADGET=m
>
> If you wish to build your own kernel, then try following the instructions
> in:
>
> https://wiki.centos.org/HowTos/Custom_Kernel
>
> Or you could build just a module instead of a whole kernel:
>
> https://wiki.centos.org/HowTos/BuildingKernelModules
>
> Akemi
>
> Hi Akemi
>
> Yep, did all of those... Interesting rat hole(s) and good information.
> Turns out I don't need g_ether on the Scientific Linux side.
>
> it *looks* like a hotplug event is supposed to load a driver to create and
> interface usb0.  More digging is required.
>
> Thanks for your attention!
>
> BTW, if someone knows the module that's supposed to load... It'd save me
> some time, but I can dig more too.
>
I'll suggest that you try something like the following --

$ lsusb > unconnected.txt
Plug in the device.
$ lsusb > connected.txt
$ diff unconnected.txt connected.txt

-- and then report the hexadecimal ID pairing. From that, we might be
able to deduce the required driver.

Here's my real-life example --

[Duo2 tmp]$ lsusb > unconnected.txt
[Duo2 tmp]$ # Plugged in the device.
[Duo2 tmp]$ lsusb > connected.txt
[Duo2 tmp]$ diff connected.txt unconnected.txt
1d0
< Bus 002 Device 002: ID 0b95:7720 ASIX Electronics Corp. AX88772
[Duo2 tmp]$

-- the hexadecimal ID pairing for my example being 0b95:7720. That ID
pairing points to the asix driver.

Alan.

Re: Tip: when your terminal gets all screwed up

[Alan Bartlett]

On 11 November 2017 at 14:33, Steven Haigh  wrote:
> On Sunday, 12 November 2017 1:30:45 AM AEDT Nico Kadel-Garcia wrote:
>> On Sat, Nov 11, 2017 at 8:10 AM, Tom H  wrote:
>>
>> [ Hundreds of lines of fine-tuning prompt manipulation code and theory
>> snipped, especially involving quote handling ]
>>
>> And *this* is why I ignore it all and just use "stty sane" when my
>> console gets confused.
>
> heh - personally, I just type: reset
>
> --
> Steven Haigh

Coming from Unix System III, of many, many, years ago, my "magic
incantation" is just that prefixed and suffixed by .

I.e.: reset

Alan.

Re: yum update errors

[Alan Bartlett]

On 19 September 2017 at 23:09, Lofgren, Eric  wrote:
> We’ve got a seldom-used workstation running SL7, which I try to update 
> whenever I’m on the machine.
>
> This last time, I encountered an error running sudo yum update, I got the 
> following error:
>
> ---> Package libplist.x86_64 0:1.10-4.el7 will be updated
> --> Processing Dependency: libplist.so.1()(64bit) for package: 
> libgpod-0.8.3-14.el7.x86_64
> ---> Package usbmuxd.x86_64 0:1.0.8-11.el7 will be obsoleted
> --> Processing Dependency: libusbmuxd.so.2()(64bit) for package: 
> libgpod-0.8.3-14.el7.x86_64
> --> Finished Dependency Resolution
> Error: Package: libgpod-0.8.3-14.el7.x86_64 (@epel)
>Requires: libusbmuxd.so.2()(64bit)
>Removing: usbmuxd-1.0.8-11.el7.x86_64 (@base/$releasever)
>libusbmuxd.so.2()(64bit)
>Obsoleted By: usbmuxd-1.1.0-1.el7.x86_64 (sl-security)
>Not found
> Error: Package: libgpod-0.8.3-14.el7.x86_64 (@epel)
>Requires: libimobiledevice.so.4()(64bit)
>Removing: libimobiledevice-1.1.5-6.el7.x86_64 (@base/$releasever)
>libimobiledevice.so.4()(64bit)
>Updated By: libimobiledevice-1.2.0-1.el7.x86_64 (sl-security)
>   ~libimobiledevice.so.6()(64bit)
> Error: Package: libgpod-0.8.3-14.el7.x86_64 (@epel)
>Requires: libplist.so.1()(64bit)
>Removing: libplist-1.10-4.el7.x86_64 (@base/$releasever)
>libplist.so.1()(64bit)
>Updated By: libplist-1.12-3.el7.x86_64 (sl-security)
>   ~libplist.so.3()(64bit)
>  You could try using --skip-broken to work around the problem
> ** Found 4 pre-existing rpmdb problem(s), 'yum check' output follows:
> ipa-client-4.4.0-14.sl7_3.7.x86_64 has installed conflicts freeipa-client: 
> ipa-client-4.4.0-14.sl7_3.7.x86_64
> ipa-client-common-4.4.0-14.sl7_3.7.noarch has installed conflicts 
> freeipa-client-common: ipa-client-common-4.4.0-14.sl7_3.7.noarch
> ipa-common-4.4.0-14.sl7_3.7.noarch has installed conflicts freeipa-common: 
> ipa-common-4.4.0-14.sl7_3.7.noarch
> ipa-python-compat-4.4.0-14.sl7_3.7.noarch has installed conflicts 
> freeipa-python-compat: ipa-python-compat-4.4.0-14.sl7_3.7.noarch
>
> Trying yum update —skip-broken yields an error as well…
>
> -> Finished Dependency Resolution
>
> Packages skipped because of dependency problems:
> 1:NetworkManager-1.8.0-9.el7.x86_64 from sl-security
> 1:NetworkManager-adsl-1.8.0-9.el7.x86_64 from sl-security
> 1:NetworkManager-glib-1.8.0-9.el7.i686 from sl-security
> 1:NetworkManager-glib-1.8.0-9.el7.x86_64 from sl-security
> 1:NetworkManager-libnm-1.8.0-9.el7.x86_64 from sl-security
> NetworkManager-libreswan-1.2.4-2.el7.x86_64 from sl-security
> NetworkManager-libreswan-gnome-1.2.4-2.el7.x86_64 from sl-security
> 1:NetworkManager-ppp-1.8.0-9.el7.x86_64 from sl-security
> 1:NetworkManager-team-1.8.0-9.el7.x86_64 from sl-security
> 1:NetworkManager-tui-1.8.0-9.el7.x86_64 from sl-security
> 1:NetworkManager-wifi-1.8.0-9.el7.x86_64 from sl-security
> PackageKit-1.1.5-1.sl7.x86_64 from sl-security
> PackageKit-command-not-found-1.1.5-1.sl7.x86_64 from sl-security
> PackageKit-glib-1.1.5-1.sl7.x86_64 from sl-security
>
> …snip a huge number of packages…
>
> webkitgtk3-2.4.11-2.el7.x86_64 from sl-security
> webkitgtk4-2.14.7-2.el7.x86_64 from sl-security
> webkitgtk4-jsc-2.14.7-2.el7.x86_64 from sl-security
> webkitgtk4-plugin-process-gtk2-2.14.7-2.el7.x86_64 from sl-security
> webrtc-audio-processing-0.3-1.el7.x86_64 from sl-security
> xkeyboard-config-2.20-1.el7.noarch from sl-security
> xorg-x11-apps-7.7-7.el7.x86_64 from sl-security
> xorg-x11-drv-ati-7.7.1-3.20160928git3fc839ff.el7.x86_64 from sl-security
> xorg-x11-drv-dummy-0.3.7-1.el7.x86_64 from sl-security
> xorg-x11-drv-evdev-2.10.5-2.1.el7.x86_64 from sl-security
> xorg-x11-drv-fbdev-0.4.3-25.el7.x86_64 from sl-security
> xorg-x11-drv-intel-2.99.917-26.20160929.el7.x86_64 from sl-security
> 1:xorg-x11-drv-nouveau-1.0.13-3.el7.x86_64 from sl-security
> xorg-x11-drv-qxl-0.1.5-3.el7.x86_64 from sl-security
> xorg-x11-drv-synaptics-1.9.0-1.el7.x86_64 from sl-security
> xorg-x11-drv-v4l-0.2.0-47.el7.x86_64 from sl-security
> xorg-x11-drv-vesa-2.3.2-25.1.el7.x86_64 from sl-security
> xorg-x11-drv-vmmouse-13.1.0-1.el7.x86_64 from sl-security
> xorg-x11-drv-vmware-13.2.1-1.el7.x86_64 from sl-security
> xorg-x11-drv-void-1.4.1-2.el7.x86_64 from sl-security
> xorg-x11-drv-wacom-0.34.2-2.el7.x86_64 from sl-security
> xorg-x11-proto-devel-7.7-20.el7.noarch from sl-security
> xorg-x11-server-Xorg-1.19.3-11.el7.x86_64 from sl-security
> xorg-x11-server-common-1.19.3-11.el7.x86_64 from sl-security
> xorg-x11-server-utils-7.7-20.el7.x86_64 from sl-security
> xorg-x11-utils-7.5-22.el7.x86_64 from sl-security
> xz-libs-5.2.2-1.el7.i686 

Re: SL 7.3 autoupdate failing - "dependency resolution failed"

[Alan Bartlett]

On 22 August 2017 at 23:44, Stephen L. Talbott
 wrote:
> For something like a week or two yum autoupdate on my system has been
> failing with the message
>
> Failed to check for updates with the following error message:
> Failed to build transaction: libgpod-0.8.3-14.el7.x86_64 requires
> libplist.so.1()(64bit)
> libgpod-0.8.3-14.el7.x86_64 requires libimobiledevice.so.4()(64bit)
> libgpod-0.8.3-14.el7.x86_64 requires libusbmuxd.so.2()(64bit)
>
> Each of the required files is currently installed on my system.  If,
> which is doubtful, I understand the error output from Yum Extender
> (shown below), the problem somehow arises from the fact that "yum update"
> is trying to replace those required files with later versions.  I can
> find no information about how to resolve the situation. "Yum clean"
> hasn’t helped.
>
> There are something like 270 packages currently requiring updating on my
> system, but the errors appear to be (for me) showstoppers.  --skip-broken
> now skips all of them, since I ran it earlier to install whatever packages
> I could.  If there are any obvious routes of attack on the problem, I
> would appreciate hearing about them.  But I am not an admin type, so if
> the problem is complex, I would also be interested in knowing whether
> there is a resource somewhere where one can find (qualified!) admins who
> are in the market for occasional, long-distance, paid consultation.  I
> could use such a connection in any case as an alternative to bothering
> this list — in which, I am afraid, I really don’t belong (although I do
> receive useful information from *reading* it).
>
> Many thanks.
>
> ##
> “Dependency Resolution Errors” resulting from an attempt to manually run
> 'yum update' from the Yum Extender utility:
>
>16:25:59 : ERROR: Dependency resolving completed with errors
>16:25:59 : ERROR:   Package: libgpod-0.8.3-14.el7.x86_64 (@epel)

Please try the following:

yum --disablerepo epel update

The problem seems to originate with a package from the EPEL repository.

Alan.

Re: Kernel Local Privilege Escalation - CVE-2016-5195

[Alan Bartlett]

On 20 October 2016 at 23:32, Akemi Yagi  wrote:
>
> As far as I can see, it is not trivial to apply the patch to the
> current EL kernels. Hopefully Red Hat publishes the patched kernel
> soon.
>
> But if you really need to run a fixed kernel today, I suggest you
> install the latest kernel-ml from ELRepo. It is version 4.8.3 and does
> contain the referenced patch.
>
> http://elrepo.org/tiki/kernel-ml
>
> Akemi

Further to Akemi's note (above), the latest kernel-lt (EL5, EL6 & EL7)
and the latest kernel-ml (EL6 & EL7) package sets, available from the
ELRepo Project, all contain the upstream patch (commit
19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619).

Alan.

Re: Adding files to the sl repo

[Alan Bartlett]

On 6 June 2015 at 05:03, Stephen John Smoogen smo...@gmail.com wrote:


snip

 RHEL 20 and 21 might . . .

snip

Either I have been asleep for a very long time or perhaps application
of s/RHEL/Fedora/ is appropriate. ;-)

Alan.

Re: What library is needed to have X11 borders?

[Alan Bartlett]

On 27 February 2015 at 00:58, DBC d...@usa.net wrote:
 How do I unsubscribe to this list?

The third bullet point at
http://listserv.fnal.gov/archives/scientific-linux-users.html will be
your guide.

Re: video and media supp in SL7?

[Alan Bartlett]

On 26 October 2014 19:52, Jason Bronner jason.bron...@gmail.com wrote:
 You can get away with most playback using the FFMPEG package and VLC Media
 Player, FFMPEG is generally available on ATRPMS, ELREPO, and RPMFORGE. VLC
 Media player has a native .RPM for Enterprise Linuxes on videolan.org. Those
 two seem to bug the least and work the best across platforms for me for
 playback and encode/decode.

Just a quick correction.

We, the ELRepo Project [1], do not carry an rpm for ffmpeg in our
repositories. For a reliable source of that utility please check with
EPEL [2].

Alan.

[1] http://elrepo.org
[2] https://fedoraproject.org/wiki/EPEL

Re: how do I run this java program?

[Alan Bartlett]

On 18 January 2014 00:36, ToddAndMargo toddandma...@zoho.com wrote:
 Hi All,

 How do I run this java program to administer an Apple Airport router?
 Do I need to compile it?

 http://edge.cs.drexel.edu/GICL/people/sevy/airport/configurator_201.zip

 which is located on
 http://edge.cs.drexel.edu/GICL/people/sevy/airport/

 Many thanks,
 -T

From the included documentation --

[quote]
Java-Based Airport Base Station Configurator

The Airport Base Station Configurator is a Java application which is
used to inspect and change the configuration of Apple's Airport Base
Station. Apple itself offers software to provide this functionality;
however, it requires a Macintosh running Mac OS 8.6 or greater to run.
This application, being written entirely in Java, will run on any host
which has a Java Runtime Environment installed, including
Windows-based machines and most Unix variants.


Running the Configurator

To run the configurator, cd into the directory containing it and
type java -jar AirportConfigurator.jar. If you get an error message,
you may not have the Java Runtime Environment installed. On Windows
machines, you may alternately run the software by simply
double-clicking on the file AirportConfigurator.jar.
[/quote]

Alan.

Re: how to change the CD mount point

[Alan Bartlett]

On 15 October 2013 23:36, Paul Robert Marino prmari...@gmail.com wrote:
 The automount tools in the GUI usually use the label of the CD as the mount
 point so the only way to ensure the name is the same regardless of the label
 is to specify it in the /etc/fstab file.
 And yes that line should work in SL6

Just remember to remove 'kudzu' from the options for SL6:

/dev/cdrom /mnt/cdrom udf,iso9660 noauto,owner,ro 0 0

Re: firefox java plugin

[Alan Bartlett]

On 10 September 2013 14:01, Andrew Z form...@gmail.com wrote:
 Alan,
 Somewhat late to thread, but did java.com confirmed that your java plugin
 working?
 Thank you
 AZ

As far as I can recall, taking the following link --

http://java.com/en/download/installed.jsp

confirmed that the plugin was operating correctly.

Sorry to be somewhat vague but I no longer have the icedtea-web and
java-1.7.0-openjdk packages installed on this RHEL 6u4 system.

Alan.

Re: firefox java plugin

[Alan Bartlett]

On 3 September 2013 16:56, Tom Rosmond rosm...@reachone.com wrote:
 Alan,

  'icedtea-web' was installed as part of the build, so that doesn't
 address this problem, I'm afraid.

 T. Rosmond

Hmm . . . Odd. The more I think about it, the more convinced I am that
'icedtea-web' and 'java-1.7.0-openjdk' were all that I required to
have a working java plugin for firefox on a pure 64-bit RHEL 6 system.

Alan.

Re: firefox java plugin

[Alan Bartlett]

On 3 September 2013 19:03, Tom Rosmond rosm...@reachone.com wrote:
 Alan,

 Now java seems to be working (on a couple of websites I've tried).
 Yesterday it wasn't, but I did a lot of yum repository activity, and
 maybe I stumbled onto a solution.  Sometimes even a blind dog can find a
 bone.  Thanks for the suggestions.

 T. Rosmond

You now have it working and that's all that really matters.

Thanks for letting me know.

Alan.

Re: SL 6.4/mplayer

[Alan Bartlett]

On 2 September 2013 21:42, Tom Rosmond rosm...@reachone.com wrote:
 Over the weekend on my workstation I did an SL re-install from 5.5 to
 6.4.  So far my system seems to be running everything I want, with one
 exception.  I had 'mplayer' working under 5.5, but have a problem with
 6.4.  I tried to install it from 2 different repos (atrpms, dag), but in
 both cases there is a missing dependency with 'libltdl.so.3'.  This
 library was apparently available in 5.5, but in 6.4 has been upgraded to
 'libltdl.so.7', and the 'mplayer' RPM's aren't compatible.  It is easy
 to download and install the older version from the typical sites.
 However, are there any unforeseen consequences doing this that might
 cause problems?  Or is there a preferred application from playing videos
 (e.g. AVI files), in 6.4.

 T. Rosmond

I have found that the mplayer package from the LinuxTECH repository
[1][2][3] is a perfect replacement for that which was previously
available from Repoforge (a.k.a. RPMforge).

Alan.

[1] http://pkgrepo.linuxtech.net/el6/
[2] http://pkgrepo.linuxtech.net/el6/release/linuxtech.repo
[3] http://pkgrepo.linuxtech.net/el6/release/RPM-GPG-KEY-LinuxTECH.NET

Re: CONFIG_EEEPC_LAPTOP is not set

[Alan Bartlett]

On 11 March 2013 00:59, Steven Haigh net...@crc.id.au wrote:
 On 11/03/2013 1:13 AM, Akemi Yagi wrote:

 On Sun, Mar 10, 2013 at 6:56 AM, Steven Haigh net...@crc.id.au wrote:

 On 11/03/13 00:52, Akemi Yagi wrote:

 On Sun, Mar 10, 2013 at 4:50 AM, Steven Haigh net...@crc.id.au wrote:

 Not sure if this has come in from upstream or something local, but it
 looks
 like CONFIG_EEEPC_LAPTOP is no longer set in the kernel config. This
 reduces
 battery life significantly on Asus EEEPCs loading with linux.

 Kernel is: kernel-2.6.32-358.el6.x86_64
 Install is fresh from the SL6.4 Beta 2 iso.

 I don't think CONFIG_EEEPC_LAPTOP was ever enabled in the TUV
 (therefore SL as well) kernel. Just for a reference, the CentOSPlus
 kernel has it enabled. But that is a custom kernel, not a distro one.

 Its a bit strange here... the 32 bit kernel has it enabled and built as a
 module. The 64 bit kernel has it disabled.

 I'm not quite sure why that is...

 You are quite right. I only checked the 64-bit kernel.

 The problem with this is as it stands (no module for the eeepc), it gets
 ~3.5 hours on battery vs Windows 7 which gets nearly 5 hours. The 'SHE'
 function provided by this module is paramount to getting any kind of decent
 battery life on the Asus EEEPC laptop range.

Please open a bug report, upstream. [1]  Then, as a temporary measure,
consider using the kernel-lt package from the ELRepo Project. [2]
CONFIG_EEEPC_LAPTOP is configured as a module is both 32- and 64-bit
flavours.

Alan.

[1] https://bugzilla.redhat.com/frontpage.cgi
[2] http://elrepo.org/tiki/kernel-lt

Re: CONFIG_EEEPC_LAPTOP is not set

[Alan Bartlett]

On 11 March 2013 02:06, Steven Haigh net...@crc.id.au wrote:
 On 11/03/2013 12:58 PM, Alan Bartlett wrote:

 Please open a bug report, upstream. [1]  Then, as a temporary measure,
 consider using the kernel-lt package from the ELRepo Project. [2]
 CONFIG_EEEPC_LAPTOP is configured as a module is both 32- and 64-bit
 flavours.

 Alan.

 [1] https://bugzilla.redhat.com/frontpage.cgi
 [2] http://elrepo.org/tiki/kernel-lt


 A - thanks Alan, I wasn't aware of the elrepo kernels. Saves me a lot of
 messing around ;)

You're welcome.

 I'll still BZ it though...

Please do so, for the sake of all other EL6 users.

Alan.