Re: lx-390] Unsubscribe

[R P Herrold]

On Wed, 22 Jul 2020, Brown, Duncan wrote:

> Ok - how do I Unsubscribe from this list?  I've sent this a few times now...

your mail reader may be hiding the footer:



For LINUX-390 subscribe / signoff / archive access
instructions, send email to
lists...@vm.marist.edu
with the message:
INFO LINUX-390 or
visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390


-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Open Source, drug dealers, and time travel

[R P Herrold]

On Mon, 6 Jul 2020, Phil Smith III wrote:

> Time Travel Resistant Cryptography
>
> https://www.bluetoad.com/publication/?m=1336 
> 
>  =666070=articleBrowser_id=3713491

rather ignorant of the motivations for __ contributing __ to
an Open Source project [speaking as one of the three founders
of CentOS].  The author does not not mention, nor does he
seem to have read Eric Raymond's _The Cathedral and the
Bazaar_, and restates the old chestnut FUD about 'dangerous'
Open Source

not worth reading

-- Russ herrold
(time traveller)

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

just: also COBOL

[R P Herrold]

On Mon, 6 Apr 2020, Rick Troth wrote:

> Bonus package (but not new), Gnu COBOL ...
>
> rsync://chic.casita.net/opt/gnucobol-1.1/
>
> rsync://chic.casita.net/opt/gnucobol-2.2/
>
> The 1.1 build gets used from time to time. (32-bit Intel Linux)
> The 2.2 build is untested.

There was an OpenCOBOL in Fedora through their 23 release ...
so until about five years ago.  The package no longer builds
due to the removal of 'db4 support' -- Red Hat / Fedora had
lots of words about license changes which I did not see were
true, but * shrug *   Their circus, their monkeys

There is a fairly mechanical writeup in pushing an OpenCOBOL 1.
forward into the 2. product at [1].  Once I get a build solved
under ClefOS 8 [in process], I'll see about getting it in
there as well as in back into ClefOS 7


-- Russ herrold

1. https://sourceforge.net/p/open-cobol/discussion/cobol/thread/d4be157a/

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Issues trying to install RHEL 8

[R P Herrold]

On Tue, 30 Jul 2019, Martha McConaghy wrote:

> Has anyone run into problems getting RHEL 8 to install on Z? I've run into a

Interesting suggestions all in this thread.  /me waves 'hi' to
Smooge ;)


I see a couple of moving parts here:

1 missing modules in a virtualization environment
this may still persist, as it is not a well-tested
path

2. inability to turn up the ethernet interface (shown in your
report) possibly due to a re-naming. p[possibly due to a
missing module


My research showed two possibly relevant bugs in the Red Hat
public tracker

https://bugzilla.redhat.com/show_bug.cgi?id=1396217

https://bugzilla.redhat.com/show_bug.cgi?id=1396217
   missing modules in a virtualization environment


https://bugzilla.redhat.com/show_bug.cgi?id=1680049

"[   10.810441] localhost multipathd[933]: dasda: failed to
get udev uid: Invalid"
argument

"[   10.367618] localhost dracut-pre-udev[534]: modprobe:
FATAL: Module sha256 no"
"t found in directory /lib/modules/4.18.0-32.el8.s390x"

"[   10.530096] localhost systemd-udevd[834]: link_config:
autonegotiation is uns"
"et or enabled, the speed and duplex are not writable."
"[   10.530308] localhost systemd-udevd[834]: Could not set
Alias=, MACAddress= o"
"r MTU= on eth0: Resource temporarily unavailable"
"[   10.530334] localhost systemd-udevd[834]: Could not apply
link config to eth0"
", ignoring: Resource temporarily unavailable"
"[   10.533283] localhost systemd-udevd[756]: Process
'ccw_init' failed with exit"
"code 1."

comment 7

The problem seems to be in an incorrect name of the network
device specified on the kernel command line:

rd.znet=qeth,0.0.a700,0.0.a701,0.0.a702,layer2=1,portno=0
ip=10.62.40.144::10.62.40.1:24:zll0009:enccw0.0.a700:none

"enccw0.0.a700" should be replaced with "enca700". It's
because of a new naming scheme for s390x network devices
introduced in
https://github.com/systemd/systemd/commit/0037a669ac9a2bbedccdb2f483111351e8ff4659

comment 13

Please Change the Dokumentation
(https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8-beta/html/installing_and_deploying_rhel/index),
because we used it as reference and there was no difference to
7.X !!!

"Example 14.1. Customized generic.prm file

ro ramdisk_size=4 cio_ignore=all,!condev
inst.repo=http://example.com/path/to/repository
rd.znet=qeth,0.0.0600,0.0.0601,0.0.0602,layer2=1,portno=0,portname=foo
ip=192.168.17.115::192.168.17.254:24:foobar.systemz.example.com:enccw0.0.0600:none
nameserver=192.168.17.1
rd.dasd=0.0.0200 rd.dasd=0.0.0202
rd.zfcp=0.0.4000,0x5005076300C213e9,0x5022
inst.ks=http://example.com/path/to/kickstart;

Thanks a lot,


Hope this gives you the needed trail-head

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

lsmem and chmem moved

[R P Herrold]

On Wed, 10 Jul 2019, Mark Post wrote:

> -snip-
> > According to the FHS, I contend it should be:
>
> In the last few years there's been a huge push to move as much as
> possible out of /bin and /sbin into /usr/bin and /usr/sbin. No idea why
> anyone thought this was a good idea, but no one asked me.

putting on my FHS hat, with which I have been active ...
wayyy too long.  Weekly call on Wednesdays at noon  ;)

Early on with spinning rust drives, /usr was mounted 'later'
and there was a need to cram whatever was really, really
needed at boot time onto the first mounted volume (even to the
extent of static linking to avoid needing /lib mounted, and
deferring mounting /bin )

With the move to 'large' initially mounted partitions (even to
the extreme of 'only one' partition holding everything), the
book-keeping / error-prone burden of combing stuff down into
/sbin could be killed off -- that is a win ;)

As to 'systemd' it regularly trips over its own shoe-laces on
such issues, wanting to use transient directories, and SELinux
labelling, and such in /run, or perhaps /var/run, or perhaps
/opt, or some legacy location.  Multiple NFS umount order
dependencies have to be specified in a systemd '.unit' file if
one needs to hold off as to /home until the last moment, but
one is indifferent as to RO mounts.  Absend such, 'deadly
embraces' and delays are common

systemd is the future we have been given, but it could use
someone employed at IBM to document it.   Someone new, that is

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Communication with z/VM DVM?

[R P Herrold]

On Mon, 17 Jun 2019, Frank M. Ramaekers wrote:

> root@mflnxclef00 ~# yum list fsiucv*

To get the 'special' "*" passed in to yum, one has to escape
it with a backslash as I recall

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Messages booting SLES12 SP3

[R P Herrold]

On Tue, 23 Oct 2018, Neale Ferguson wrote:

> I added a disk to the system and now when I did a shutdown -r now I am seeing 
> this message repeated ad infintum at boot time:
>
> A start job is running for dev-disk...x2dpart2.device (42s / no limit)  [OK]
>
> What have I stuffed up?

Did you explicitly 'dd' off any labels from prior usage ?

Also remember that LVM looks beyond the first sector (and
offset multiples), and needs to be 'scratched' with the tools
in the lvs2 suite.  the LVM is sneaky enough to sniff for and
then to 'see' old layout data, and to try to assemble a
partially broken drive into its coverage

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

clefOS logical volumes

[R P Herrold]

On Wed, 22 Aug 2018, Phillip Gramly wrote:

> I want to set up a lv, but i find that clefOS does not have any of the
> commands installed (pvcreate, vgcreate, lvcreate)
>
> do i need to install some package(s) in order to get this capability?

yes

A general solution to identify the owning package when one
knows an executable name is to query the databases (there are
several files, which slice and dice the search process) used
by the package manager:
$ yum provides \*/pvcreate

which reveals that:
7:lvm2-2.02.177-4.el7.s390x : Userland logical volume
management tools
Repo: base
Matched from:
Filename: /usr/sbin/pvcreate

so installing 'lvm2' is in order:
# yum install lvm2

That information in those indexing files goes stale as updates
issue, so occastionally one needs to re-fresh the data.  The
quickest habit to have to do this is to run:
# yum clean all

-- Russ herrold



--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Advice on indexing PDFs

[R P Herrold]

On Fri, 10 Aug 2018, Frank M. Ramaekers wrote:

> Ugh!   Tried 3.3.15:
>
> checking for MySQL support... no
> configure: error: Unknown MySQL directory - unable to find mysql.h
>
> Okay, so I figure mariadb-devel is  not installed:
>
> # yum info mariadb-devel
> Loaded plugins: fastestmirror, langpacks
> Loading mirror speeds from cached hostfile
> Available Packages
> Name: mariadb-devel
> Arch: s390
> Epoch   : 1
> Version : 5.5.56
> Release : 2.el7
> Size: 751 k
> Repo: base/7/s390x


Yesterday you were using:

> I want to move the website to a
> ClefOS (CentOS) 4.7 install on zLinux

One assumes:
 CentOS Linux release 7.5.1804 (Core)

and I see in the archive:

Name: mariadb-devel
Arch: s390x
Epoch   : 3
Version : 10.2.8
Release : 2.el7
Size: 992 k
Repo: epel


What in the world is carrying around:
mariadb-devel 5.5.56?

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: xymon on zLinux anyone?

[R P Herrold]

On Tue, 24 Jul 2018, R P Herrold wrote:

> form, as it locks in potentially vulnerable library decisions
> (I see some compression / decompression libraries which have
> had CVE type vulnerabilities in them, so this matters -- a
> stale 'carried in the tarball' lzo [YIKES], a stale 'carried
> in the tarball' l4 [YIKES], zlib, more with unpackaged perl

heh -- one of the holes is well enough known, and the code
stale and unfixed, that the GCC suite and glibc, know to warn
during a build:

+ make V=1 PKGBUILD=1 client
compression.c: In function 'compress_message_to_strbuffer':
compression.c:352:3: warning: 'LZ4_compressHC' is deprecated
(declared at /usr/include/lz4hc.h:203): use LZ4_compress_HC()
instead [-Wdeprecated-declarations]
   newsize = LZ4_compressHC(datasrc, STRBUFEND(deststrbuffer),
datasz);
   ^
compression.c:364:3: warning: 'LZ4_compress' is deprecated
(declared at /usr/include/lz4.h:431): use
LZ4_compress_default() instead [-Wdeprecated-declarations]
   newsize = LZ4_compress(datasrc, STRBUFEND(deststrbuffer),
datasz);
   ^

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: xymon on zLinux anyone?

[R P Herrold]

On Tue, 24 Jul 2018, Martha McConaghy wrote:

> We use Xymon a great deal, it monitors all of our servers and network
> equipment (several thousand items).  We run the server on zLinux (SLES) and
> the client runs just about anywhere.  There are even clients for z/VM and z/OS
> (thanks Rich!). 

It looks as though a non 'package system mediated' build and 
setup process is described at:
http://xymon.sourceforge.net/xymon/help/install.html#commonsystems

It appears to do an 'interview' as part of the configuration 
process, both as to the build path decisions, and the 
hostname and network ports to be listened to, rather than 
relying on abstraction and later configuration

Also a bunch of hard linking rather than relative symlinking 
in that package's manual setup, which is usually very poor 
form, as it locks in potentially vulnerable library decisions 
(I see some compression / decompression libraries which have 
had CVE type vulnerabilities in them, so this matters -- a 
stale 'carried in the tarball' lzo [YIKES], a stale 'carried 
in the tarball' l4 [YIKES], zlib, more with unpackaged perl 
modules [YIKES])

The _problem_ with this approach is that one can unknowingly 
carry around exploitable libraries rather than have the 
benefit one's upsteam's maintenance, when a perl module or a 
library shows up in the security issues lists.  The crackers 
read these lists and more daily these just as I do [Credit 
card data security matters --- EDS is a big player in this 
market as well and I was ** shocked ** at the lack of 
awareness of such issues when I was dealing with them; the old 
Sterling Software had holes which I found as well, in the pre 
IBM days].  Anyway, the crackers can use stale and vulnerable 
matter as a way to prise open an entry to a remote system.  I 
'cc' the 'whitehat' exploit scanner developers 'soldier of 
fortran' and 'bigendiansmalls' so they can add coverage to 
their penetration testing tool kit


Also there is not at the SF reference site a set of 
instructions for systemd so some 'cribbing' from the work of 
others may be needed there.  Why is it not in RawHide / 
Fedoraproject already, I wonder ... a license problem (the old 
BB had that issue when it was taken non-FOSS

> On 7/24/2018 8:43 AM, Frank M. Ramaekers wrote:
> > Anyone doing xymon on zLinux?   Know where a RPM for ClefOS might be found?

Long ago and far away I ran the old Big Brother, which being 
based on lots of early perl scripts, was somewhat loady.  I 
was unaware of this package, as I run the FOSS Nagios, which 
plays well with SNMP, and had not needed to look further


Let me look at license matters and if I can solve it for an 
acceptable packaging it for ClefOS.  All the build 
Requirements are present in ClefOS, and I have a build solved 
already which I have rebuild under s390x
/home/herrold/rpmbuild/SRPMS/xymon-4.3.28-1.orc7.src.rpm

Wrote: 
/home/herrold/rpmbuild/RPMS/s390x/xymon-4.3.28-1.el7.s390x.rpm
Wrote: 
/home/herrold/rpmbuild/RPMS/s390x/xymon-client-4.3.28-1.el7.s390x.rpm
Wrote: 
/home/herrold/rpmbuild/RPMS/s390x/xymon-client-local-4.3.28-1.el7.s390x.rpm
Wrote: 
/home/herrold/rpmbuild/RPMS/s390x/xymon-devel-4.3.28-1.el7.s390x.rpm
Wrote: 
/home/herrold/rpmbuild/RPMS/s390x/xymon-tools-4.3.28-1.el7.s390x.rpm
Wrote: 
/home/herrold/rpmbuild/RPMS/s390x/xymon-debuginfo-4.3.28-1.el7.s390x.rpm


Although I do NOT like some of its choices from a system 
security POV.  a copy of my WIP SRPM is up at:
ftp://ftp.owlriver.com/pub/local/ORC/xymon/ 

but I will have a better and safer and more maintainable one 
later


-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

ClefOS setting up guest LAN for HiperSockets

[R P Herrold]

On Fri, 13 Jul 2018, Phillip Gramly wrote:

> # echo 0.0.204,0.0.205,0.0.206 > /sys/bus/ccwgroup/drivers/qeth/group
> -bash: echo: write error: Invalid argument
>
> I'm missing something somewhere. can anybody help me?

Hi, Phillip,

Thanks for using ClefOS

1.  This is just my OCD talking, but I would 'protect' that
echo, as a matter of defensive coding

echo "0.0.204,0.0.205,0.0.206" > \
/sys/bus/ccwgroup/drivers/qeth/group

I know, I know -- OCD


2.  What is shown with:

# ls -l   /sys/bus/ccwgroup/drivers/qeth/


I get this locally:

[root@lclef01 ~]# ls -l   /sys/bus/ccwgroup/drivers/qeth/
total 0

lrwxrwxrwx. 1 root root0 Jul  9 16:23 0.0.0340 -> \
../../../../devices/qeth/0.0.0340
--w---. 1 root root 4096 Jul 13 16:28 bind
--w---. 1 root root 4096 Jul  9 16:23 group
lrwxrwxrwx. 1 root root0 Jul 13 16:28 module -> \
../../../../module/qeth
--w---. 1 root root 4096 Jul  9 16:23 uevent
--w---. 1 root root 4096 Jul 13 16:28 unbind

This is pointing up into:
/sys/

and particularly I see there:

[root@lclef01 ~]# ls /sys/devices/qeth/
0.0.0340  module  power  uevent

[ I have indicated the line wrap with backslashes, although of
course not really there ]



The parallels on my settings for completeness:

[root@lclef01 ~]# vmcp q v 0340-0342
OSA  0340 ON NIC  0340  UNIT 000 SUBCHANNEL = 
 0340 DEVTYPE OSA VIRTUAL CHPID 13 OSD
 0340 MAC 02-00-10-00-00-6D CURRENT
 0340 QDIO-ELIGIBLE   QIOASSIST-ELIGIBLE
OSA  0341 ON NIC  0340  UNIT 001 SUBCHANNEL = 0001
 0341 DEVTYPE OSA VIRTUAL CHPID 13 OSD
 0341 MAC 02-00-10-00-00-6D CURRENT
 0341 QDIO-ELIGIBLE   QIOASSIST-ELIGIBLE
OSA  0342 ON NIC  0340  UNIT 002 SUBCHANNEL = 0002
 0342 DEVTYPE OSA VIRTUAL CHPID 13 OSD
 0342 MAC 02-00-10-00-00-6D CURRENT
 0342 QDIO ACTIVE QIOASSIST-ELIGIBLE
 0342
 0342 INP + 01 IOCNT = 00598184  ADP = 055 PROG = 000 UNAVAIL = 073
 0342  BYTES = 05B90B44
 0342 OUT + 01 IOCNT =   ADP = 000 PROG = 000 UNAVAIL = 128
 0342  BYTES = 
 0342 OUT + 02 IOCNT =   ADP = 000 PROG = 000 UNAVAIL = 128
 0342  BYTES = 
 0342 OUT + 03 IOCNT = 00037157  ADP = 000 PROG = 128 UNAVAIL = 000
 0342  BYTES = 006BFE58
 0342 OUT + 04 IOCNT =   ADP = 000 PROG = 000 UNAVAIL = 128
 0342  BYTES = 
[root@lclef01 ~]#


[root@lclef01 ~]# lscss --all
IO Subchannels and Devices:
Device   Subchan.  DevType CU Type Use  PIM PAM POM  CHPIDs
--
0.0.0340 0.0.  1732/01 1731/01 yes  80  80  ff   1300 
0.0.0341 0.0.0001  1732/01 1731/01 yes  80  80  ff   1300 
0.0.0342 0.0.0002  1732/01 1731/01 yes  80  80  ff   1300 
0.0.01b0 0.0.0004  3390/0c 3990/e9 yes  f8  f8  ff   0e101921 2300
0.0.0009 0.0.0006  /00 3215/00 yes  80  80  ff   1300 

CHSC Subchannels:
Device   Subchan.
--

EADM Subchannels:
Device   Subchan.
--


-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: dasdfmt assistance

[R P Herrold]

On Tue, 10 Jul 2018, Jan Höppner wrote:

> just to clear things up, the option -f/--device was deprecated
> for quite some time and got removed with s390-tools 1.37.1:
> 
> https://www.ibm.com/developerworks/linux/linux390/s390-tools-1.37.1.html

hmmm ... a early 2017 removal


Perhaps there is a workflow issue in s390-tools that the man 
page copyright needs to look at its checkin year, to 
accurately reflect when it was most recently changed in the 
emitted product

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: dasdfmt assistance...next

[R P Herrold]

On Mon, 9 Jul 2018, Frank M. Ramaekers wrote:

> Okay, I'm now stuck at expanding the logical volume (the
> whole purpose of this exercise was to expand the /home mount
> point).

> xfs_growfs /home
> xfs_growfs: /home is not a mounted XFS filesystem
>
> Hmmmnot a XFS, then what is it?   'df' only shows that it is a ext4:

xfs is a filesystem.  So is ext4

see
man mount

If you want to expand a mount, I would probably just set up a:

1. new xfs partition of the desired size, and mount it, at
say:
/tmp/home

2. then rsync the content over:

rsync -av /home/. /tmp/home/.

3. run the command twice, 'just in case'

4. umount /home, and /tmp/home

5. manually edit /etc/fstab to point to the new one

6. get SElinux properly set:
a. # touch /.autorelabel
b. # reboot

(the system will relabel)

The former [ext4 formated] /home/ partition may be scratched

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: dasdfmt assistance

[R P Herrold]

On Mon, 9 Jul 2018, Frank M. Ramaekers wrote:

> Good catch...the web page I was using has a '-f', but
> perhaps they meant '-F'...or possibly no longer viable.
> Without the nonexistent switch, it formats.

There is a later s390utils in Red Hat's RawHide archive, with
a man page showing a 2006 date.  Neither that man page, nor
the --help show the 'lower case f' option

It rebuilds locally as a scratch build thus:

$ rpmbuild --rebuild --define 'build_cflags %nil'  --define \
'build_ldflags %nil'  s390utils-2.5.0-1.fc29.src.rpm

Those two 'defines' are to accomodate some changes in rpmbuild
in its macro set since the stabilization fork of their
development line from about Fedora 19 or 20.  We are about
five years past that :)

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Alpine Linux 3.8 rc2 on z/VM and KVM

[R P Herrold]

On Thu, 21 Jun 2018, Christian Borntraeger wrote:

> I can easily boot that iso image with kvm:
>
> $ qemu-system-s390x -enable-kvm -nographic \
> -cdrom alpine-standard-3.8.0_rc8-s390x.iso
> LOADPARM=[]

Hi, Christian,

What version of qemu-system-s390x are you running?

$ qemu-system-s390x -version

RHEL 7 derived seems to have a missing feature in glib-2 ; I
have filed:
https://bugzilla.redhat.com/show_bug.cgi?id=1594304

[herrold@centos-7 ~]$ qemu-system-s390x -version

(process:17483): GLib-WARNING **: gmem.c:483: custom memory
allocation vtable not supported
QEMU emulator version 2.0.0, Copyright (c) 2003-2008 Fabrice
Bellard
[herrold@centos-7 ~]$


-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Truth/Troth what is the difference?

[R P Herrold]

On Thu, 17 May 2018, Frank M. Ramaekers wrote:

> Little help with ClefOS 7.4 install.   It seems to execute just fine until:

>  Starting Device-Mapper Multipath Device Controller...   
> Ý"Ý32m  OK  "Ý0m¨ Started Show Plymouth Boot Screen.""  
> Ý"Ý32m  OK  "Ý0m¨ Reached target Paths."" 
> Ý"Ý32m  OK  "Ý0m¨ Reached target Basic System."" 
> Ý"Ý32m  OK  "Ý0m¨ Started Device-Mapper Multipath Device  Controller."" 
>  Starting Open-iSCSI..."" 
> Ý"Ý32m  OK  "Ý0m¨ Started Open-iSCSI."" 
>  Starting dracut initqueue hook...""   
> Ý  171.594923¨ dracut-initqueueÝ608¨: 
 Warning: dracut-initqueue timeout - starting timeout scripts""

Rick and I saw this "dracut-initqueue timeout" message today, 
during what should have been a uneventful install

It is a horrid message from the installer in that it does not 
suggest that network retrieval problems are in play.  Also 
there HAS to be an option to NOT try to use: Open-iSCSI, or if 
not site local appropriate: Device-Mapper Multipath

(note to self -- file some bugs on this)

I _think_ that the: Show Plymouth Boot part may be suppressed 
by adding to the kernel boot options at this point [but am 
not sure]:

plymouth.enable=0 

(testing needed)


1. it was NOT a local network install, but rather across the 
internet (the later may work, but local is better as it 
permits disgnosing slow networking and so forth)

2. TUI, under znetboot


The installer, Anaconda, did what it could and even did a 
retry after a timeout, but without success on attaining an 
install

I am still pulling a local mirror of the 7.5 'as shipped'  
updates, and have noticed some 'hangs' in that process as 
well.  It is unclear if the congestion is on my local 'last 
hop', at the upstream, or somewhere in between

... it scarcely matters -0- one needs good connectivity for 
installs

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: ClefOS yum update error

[R P Herrold]

On Wed, 30 May 2018, Frank M. Ramaekers wrote:

> ...still can't do a 'yum update' (w/o the --disablerepo=epel):
> Error: Package: liborcus-0.12.1-2.el7.s390x (@base)
>Requires: libboost_iostreams-mt.so.1.53.0()(64bit)
>Removing: boost-iostreams-1.53.0-27.el7.s390x (@anaconda/7.4.1708)
>libboost_iostreams-mt.so.1.53.0()(64bit)
>Updated By: boost-iostreams-1.64.0-0.6.el7.s390x (epel)
>Not found

I don't think we ship a
boost-iostreams-1.64.0-0.6.el7.s390x
in base, updates, or epel

http://gallery.herrold.com/stuff/clefos-75-boost-iostreams-liborcus.png

Do you have some other archives enabled, perhaps, that we are
not running repo-closure against?

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

ClefOS yum update error

[R P Herrold]

On Wed, 30 May 2018, Frank M. Ramaekers wrote:

> I have a new ClefOS (7.4) install and when I try ('yum
> update'...well actually 'yum -skip-broken update' because of
> some dependency problems), I get
>
> I used the -skip-broken because without it, I get:
>

  snippety  ...

> Error: Package: boost-filesystem-1.53.0-27.el7.s390x (base)
>Requires: libboost_system-mt.so.1.53.0()(64bit)
>Removing: boost-system-1.53.0-27.el7.s390x (@anaconda/7.4.1708)
>libboost_system-mt.so.1.53.0()(64bit)
>Updated By: boost-system-1.64.0-0.6.el7.s390x (epel)
>Not found

There is an occasionaly re-shuffling of packages in, and out
of base RHEL [which RHEL is the upstream source from which
ClefOS] are built.  Particularly, the place that no-longer
carried, and conflicting packages are sent is 'epel' which is
managed and packages signed by Red Hat employees.  ClefOS also
grabs and rebuilds those sources and more

It looks as through with the 7.4 -> 7.5 updates, 'boost' got
shuffled out to epel (which is fine -- it chruns)

To solve that issue install and enable the
epel-release
package (the 'hint' was that: (epel) notation )

# yum -y install epel-release

I usually then force an update to the repository cache

# yum clean all

Presently, I see a conflict of which I was not previously
aware against 'gimp' which is missing a dependency.  As I do
usually not do graphics editting remotely [I was doing a show
and tell where someone asserted using a remove graphics X-top
was not doable, and that was a counter-example], I simply
removed the conflict just now:

# rpm -e gimp

and then started updates:

# yum update

(reading, there were no other conflicts, so I can answer 'y'
to the 'go ahead' question  and then rebooted:

# reboot

and in a couple minutes:

Linux lclef01.lf-dev.marist.edu 3.10.0-862.3.2.el7.s390x #1
SMP Tue May 22 20:12:01 EDT 2018 s390x s390x s390x GNU/Linux
[root@lclef01 ~]# rpm -qa kernel\*
kernel-3.10.0-693.el7.s390x
kernel-3.10.0-693.2.2.el7.s390x
kernel-3.10.0-693.5.2.el7.s390x
kernel-3.10.0-693.11.1.el7.s390x
kernel-3.10.0-862.3.2.el7.s390x


easy peasy


-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Bug with XFS and SLES 12SP3 kernel-default-4.4.131-94.29-default

[R P Herrold]

On Thu, 24 May 2018, Mike Walter wrote:

> When I was a young man learning the art of systems
> programming sooo long ago, I was taught that the first step
> of applying maintenance is to make a physical backup of the
> target volumes.  That way you have a validated source with
> which to return if/when the maintenance fails.  Just sayin'.
> :-)

hunh -0- I was taught to make and to TEST them, before letting
the SE touch the CPU

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: 7.5 package levels

[R P Herrold]

On Thu, 24 May 2018, Timothy Sipples wrote:

> Russ Herrold wrote:
> > It may turn out that we (ClefOS) need to fork and offer two
> > variants
>
> I guess I'd call them "streams" rather than "forks."

One might, but in Red Hat parlance the 'Z' [a namespace
collision here, NOT referring to Arch] extended support tail
is called a 'stream ;)

> For what it's worth, Red Hat seems to offer at least 3 major
> streams now: Fedora (their "community" release), RHEL
> Structure A, and RHEL

The argument might be made, actually that there is a fourth:
CentOS
in light of their take-over and re-casting of that project a
few years back.  As one of its three founders, I was perfectly
happy to simply keep the community's source code resources
available in a binary form, simply replicating RHEL, deviation
for deviation, bug for bug.  Post acquisition, RHT added a
plethora of distractions, and started using CentOS as a second
'testing bench' but without so much of that pesky community
'hoots and hollars' which the Fedoraproject developed

> The RHEL Structure A/RHEL pair of streams is a unique
> offering for the s390x architecture branch, at least for
> now. (Is it a one-time aberration or the start of something
> new? I have no idea, so ask Red Hat, I guess.)

I spent some time researching this yesterday.  The kernel-alt
variant seems to be timed as to release mid RHEL 7, priced and
positioned to be a 'hard core' and high volume performance
engine for (particularly Z based) Docker / Open Shift / Atomic
transient / ephemeral common kernel instances [isolated by
Linux cgroups, and SElinux], rather than lots of 'each running
a potentially different kernel' KVM Open Stack instances,
which may be long-lived.  "Open Shift" vs "Open Stack" is
another of those unfortunately chosen nameings, as the
initials 'O.S.' here as to two differing virtualization
technologies, as well as the commonly used: Operating System
;)

> In RHEL 7.5, Red Hat decided to offer kernel 3.10 (only) for
> all POWER processors prior to POWER9, and (only) kernel 4.14
> for POWER9. For X86-64 it's only 3.10, and for ARM64 it's
> only 4.14.

Look again, but think about shared kernel spaces, and it makes
more sense.  This gets RHT an uplift on the kernel (and the
nice additions for Z in 4.14) and 'buys some time' as to the
fact that the 'long lived Enterprise maintainability' model
that RHEL offers, is really _too long_ for people wanting to
respond in a more _agile_ fashion, and to also provide a
platform capable of running the 'latest and greatest'

RHEL-next (externally, and for partially historical reasons,
RHT employees do not call formally call the next Major release
'8' yet, as it has not shipped yet / some 'leaks' by others
in bug trackers call it '8') has the longest ever interval
after its prior Major.  Up to 1600 days since the RHEL 7 drop
as of Apr 30 2018.  Previous intervals were:
574 days after RHL EE 6.2E
637 days after RHEL 2.1
476 days after RHEL 3
506 days after RHEL 4
1309 days after RHEL 5
1302 days after RHEL 6

> There are certain newer capabilities that RHEL 7.5 doesn't
> support on s390x that RHEL 7.5 Structure A does. Red Hat's
> release notes explain all that.

Lots of new nuggets in those Release Notes which were not in
the Beta copy.  I'll miss sendmail, but not XFS

Actually there was a lightly publicized 'stalking horse'
'testing candidate' as well:
RHEL 7.4 variant with an -alt kernel

I again use 'variant', as it varied, and will not use the
over-loaded word: fork here ;)

> But it's possible to mix RHEL and RHEL Structure A instances
> on the same machine and in a Red Hat supported way. (And,
> for that matter, other supported RHEL releases.)

You have the benefit of potential access in light of IBM's
long time and current collaboration with RHT, and I
hope so, but building a clean testing candidate has been
tricky

It turns out there is also a difference in how an 'El Torito'
capable [needed for one deployment method on Z] CD vs a DVD
image is spun, as there are s390x specific size requirements
that differ from other Arches, and some tooling changes were
needed

It's no big deal to have this kind of delay building a
community rebuild of sources.  The test 7.5 binary packages
will 'yum update' over a base install of an earlier ClefOS 7
variant just fine.  The ability to move the absolute
underlying base kernel back and forth between the 3.10 and the
4.14 series seems unlikely, and really, not something that
might not be better done with a fresh install.  There is the
open question, which I have not tested yet, about trying a
kernel-3 to kernel[-alt]-4 transition, but again, probably
better done with a fresh install.  It will probably end up
with a minimal installer image based on each

Thank you for your insights

> 
> Timothy Sipples
> IT Architect Executive, 

Re: Bug with XFS and SLES 12SP3 kernel-default-4.4.131-94.29-default

[R P Herrold]

On Thu, 24 May 2018, Rick Troth wrote:

> Explain to me how a KERNEL update relates to a finger-pointing fest
> among three user-space packages and the users?
>
> I DO use XFS on some systems. I prolly fall into the fourth group, but
> was already pointing my digits at that second bullet.

The kernel needs to be reached, and at shutdown, left

Dracut, and early on, systemd acting as 'init' need to
transition out of an initrd into a (periodically updated)
kernel, and mount filesytems

At shutdown / reboot, filesystems need to be synced
and 'cleanly' umounted

XFS does not 'sync' as others do, and Dracut but
'plymouth' assert that it does to systemd (which does the
umounts ...)  So arbitrary FS may be left marked 'dirty' and
in need of recovery

But the new kernel does not have all the tools it needs to get
there

Read the (horrifying as to denials of accountability, and a
lack of 'taking ownership' and fixing stuff) thread

> Here is a trailhead to read back and forth from:
>http://tinyurl.com/y7d2a4he

As to Alan's later question, it was over on the Fedoraproject
'side of the house' [where breaking stuff is considered a
feature], and the RHEL 7.5 release notes indicate an intent to
no longer seek to 'mainstream' XFS going forward

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Bug with XFS and SLES 12SP3 kernel-default-4.4.131-94.29-default

[R P Herrold]

On Wed, 23 May 2018, Ted Rodriguez-Bell wrote:

> Suse just released a new kernel-default-4.4.131-94.29-1
> package for SLES 12SP3 with some kernel security fixes.  If
> you use XFS, don't install it!

My condolences

There has been an (at least) four way finger pointing contest
raging for the last couple of months (on the Fedoraproject
front) between:
- xfs developers
- systemd developers
- dracut developers
- innocent victims of XFS

Here is a trailhead to read back and forth from:
http://tinyurl.com/y7d2a4he

I have a number of Red Hat Bugzilla reports I track, I have
corresponded twice privately with the Fedoraproject lead about
applying dynamite to at least get the innocent victims out of
XFS' harm's way, and ... bupkis.  I have to say the problem
looks well and truly wedged, and XFS and data I care about
will never meet

In response, I went into our local deployment SOP's and added
a general prohibition on using XFS, absent explicit prior
approval from an admin or greater level authority.  The ONLY
exception I can see being sought relates to extremely large
filesystems

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: 7.5 package levels

[R P Herrold]

On Wed, 23 May 2018, Timothy Sipples wrote:

> There's a new dual build/delivery approach that Red Hat has
> introduced with RHEL 7.5. RHEL 7.5 offers an alternate build
> stream called "Structure A,"

One reason for Neale's questions in part are that the ClefOS
7.5 build has been being bitten by the two tracks, as we have
tried to spin and test updated ISOs.  The post drop release
notes add color that was not in the Beta release notes

It may turn out that we (ClefOS) need to fork and offer two
variants

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Red Hat/ClefOS configuration file

[R P Herrold]

On Tue, 22 May 2018, Frank M. Ramaekers wrote:

> just one more thing:
>
> Initial setup of CentOS Linux 7 (Core)

ClefOS requires no acceptance of a license -- there is a
'firsttime' configuration tool in some of the sources, which
it looks like we missed turning off, along with 'branding' sed
as to distribution name there on our end

You may safely answer yes without future entaglements ;)

I had not see it as I never run a GUI Desktop environment, I
guess

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Red Hat/ClefOS configuration file

[R P Herrold]

On Tue, 22 May 2018, Frank M. Ramaekers wrote:

> Well, I never could get it installed using TEXT mode, so I tried VNC 
> (graphical) and had no problems.

congratulations -- welcome aboard

run your updates and boot please   ;)

-- Russ

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Red Hat/ClefOS configuration file

[R P Herrold]

On Tue, 22 May 2018, Neale Ferguson wrote:

> My kickstart uses url --url="http://download.sinenomine.net/clefos/7; so I am 
> not sure why you are not getting anything. 
> 
> On 5/22/18, 14:47, "Linux on 390 Port on behalf of Frank M. Ramaekers" 
>  wrote:
> 
> Thanks allgetting further.

Hi, Frank

Recall that the URL mangling which you mentioned you saw would 
bite here

As I recall, in a text mode install, alt-F7 or such changed to 
different VT's so you could view what was being sent (the 
details are on one of the secondary initial boot screens, 
which you many toggle between)

Not sure what your network map looks like, of course, but 
before you beat yourself up, talk with your networking support 
about getting an unfiltered port 

Alternatively a 'mirror' can be set up 'inside' the 
protected perimeter and on the same network segment as the 
target machine to be installed, on a local PC running 
Linux fairly trivially

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Red Hat/ClefOS configuration file

[R P Herrold]

On Tue, 22 May 2018, Frank M. Ramaekers wrote:

> I'm following in the IBM Redbook "The Virtualization Cookbook for IBM z 
> Systems Volume 2: Red Hat Enterprise Linux 7.1 Servers", and I'm at step 6:

> Where do I find out what the various operands are for each keyword 
> (especially the ip=)?   I'm assuming the ip= is:

One assumes:
https://www.redbooks.ibm.com/redbooks/pdfs/sg248303.pdf
tiny URL:   http://tinyurl.com/y92gwnqn

RHEL 7.1 was some time ago.  RHEL 7 first dropped: 2014 06 10

A better resource (in terms of being specific to Red Hat's
most current approach -- 7.5 dropped in beta: 2018 01 24, and
formally as an update: 2018 04 24) is the documentation they
maintain [I opened a few bugs on it during the beta period
which were promptly and professionally addressed.  The net net
is that is was clear that Red Hat and IBM were explicitly
working (sadly in private bugs) on the 7.5 Release Notes in
to correct some detail in RH's documentation presence]

There are some quesions about Red Hat having unwittingly
changed exported headers in kernel-devel with the 'kernel-alt'
package series.  Recall the mention by Neale noticed of some
side effects flowing through to python 2, and systemd, as side
effects of last week, (repository closure was broken, more)
and which have delayed the formal ClefOS 7.5 update respin a
bit as the parts for a good installing ISO are sorted out

ClefOS 7.4 is fine

Anyway, back to your question.  A more current resource might
be:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/installation_guide/part-installation-system-z

short URL:  http://tinyurl.com/yd3cpuks

at sections 15 and following

Section 22.4 answers your question as to the colon
separated options for 'ip='

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: ClefOS 7.4 installation (was: RE: Truth/Troth what is the difference?)

[R P Herrold]

On Mon, 21 May 2018, Frank M. Ramaekers wrote:

> Can someone tell me where to find what the url below is
(root=),

> it appears we have some sort of dummy protection on urls.
> (If I enter it, in it's entirety, it attempts to download.)

> root=live:

> junk https://urldefense.proofpoint.com/v2/url?u=

http : / / download .  sinenomine . net /
clefos / 7 / images / install . img
 ramdisk_size=131072 cio_ignore=all,!0.0.0009


Is there not an 'ro' between the img and the ram... ? see:
http://download.sinenomine.net/clefos/7/images/generic.prm


good heavens --- all one line for that [whitespace after 'img'
and before 'ramdisk...' ].  If your network people are doing
this, you need to take one into the back room, and convince
that person that it is in their better interest to get an IP
opened up without such   ;)

it may work for you to clone the installer tool Rick and I are
working on locally, to get good documentation inside your site
filtering

cd wherever
mkdir ZNETBOOT
cd ZNETBOOT
git clone https://github.com/trothr/znetboot

which has most of the link information which you seek
inside its content

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Getting verbose output during boot

[R P Herrold]

On Wed, 16 May 2018, Neale Ferguson wrote:

> The problem appears to be related to this message during the
> build of the initramfs:
>
> error: Failed to initialize NSS library
>
> This left initrd.img in a less than stellar state.

The initrd [Initial Ram Disk] is generated into an
appropriately sized, loop mounted file as part of the Anaconda
image building process.  The initrd has a filesystem laid down
on it, and touching 'dracut' and 'grubby', which in turn pulls
in a plethora of modules, for the udevd and friends.  Also,
and to their credit, Red Hat has drilled back the SELinux MAC
enforcement back into this phase of a boot cycle as well

Over on the Distributed side of the house, this makes it
possible to go from TPM hardware security module protected,
all the way to a running system, with strong Role Based
controls all the way through.  Some believe it to be less
importent in a Mainframe, but I am no longer so convinced,
based on the work by Chad Rikansrud and Phil Young

I've pointed Neale at a couple of debugging candidates to look
at.  There has been a lot of recent churn and a coupld of
CVE's at Red Hat on former 'Free IPA' and related security
modules (NSS is such), and I suspect that the generation of
this initrd is a bit fragile

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Linux "sleep" command not waking up under high CPU utilization

[R P Herrold]

On Wed, 18 Apr 2018, John Campbell wrote:

> "This should not happen"...  Never confuse theory with practice.

The tell-tale give-away is the use of the verb form:
should

as it indicates the speaker is working from expectation rather
than observation

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

RHEL and HMC load from FTP

[R P Herrold]

On Fri, 23 Mar 2018, munif sadek wrote:

> Now when I am trying to use -RECOVERY -> Load from Removable Media or
> Server, I am getting
>
> "An error occurred while trying to obtain a list of software that can
> be loaded. Please verify the information you entered and that the
> correct media in the selected drive." ACT36201

> Rsp: 200 Representation type is Ascii NonPrint
> Req: NLST /software/RHEL/generic.ins/.
> Rsp: 550 No data sets found.

that looks, all the world, like a blocked read permissions
problem somewhere in the chain, over on the FTP Server side

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Meltdown/Spectre; Linux on z affected?

[R P Herrold]

Red Hat has been walking through the day, assumedly completing
QA qualification on patched builds, and then issuing
microcode, and virtualization technologies (qemu first), not
libvirt, with updates ** including PPCx and s390x ** , on both
their publicly in support '6 and '7 products, and parts of
their available 'Z' channel of updates after formal EOL

-- Russ herrold

-- Forwarded message --
Date: Thu, 4 Jan 2018 13:33:12
From: Security announcements for all Red Hat products and services.

To: rhsa-annou...@redhat.com
Subject: rhsa] Important: libvirt security update

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

=
   Red Hat Security Advisory

Synopsis:  Important: libvirt security update
Advisory ID:   RHSA-2018:0030-01
Product:   Red Hat Enterprise Linux
Advisory URL:  https://access.redhat.com/errata/RHSA-2018:0030
Issue date:2018-01-04
=

1. Summary:

An update for libvirt is now available for Red Hat Enterprise Linux 6.

Red Hat Product Security has rated this update as having a security impact
of Important. A Common Vulnerability Scoring System (CVSS) base score,
which gives a detailed severity rating, is available for each vulnerability
from the CVE link(s) in the References section.

2. Relevant releases/architectures:

Red Hat Enterprise Linux Desktop (v. 6) - i386, x86_64
Red Hat Enterprise Linux Desktop Optional (v. 6) - i386, x86_64
Red Hat Enterprise Linux HPC Node (v. 6) - x86_64
Red Hat Enterprise Linux HPC Node Optional (v. 6) - x86_64
Red Hat Enterprise Linux Server (v. 6) - i386, ppc64, s390x, x86_64
Red Hat Enterprise Linux Server Optional (v. 6) - x86_64
Red Hat Enterprise Linux Workstation (v. 6) - i386, x86_64
Red Hat Enterprise Linux Workstation Optional (v. 6) - x86_64

3. Description:

The libvirt library contains a C API for managing and interacting with the
virtualization capabilities of Linux and other operating systems. In
addition, libvirt provides tools for remote management of virtualized
systems.

Security Fix(es):

* An industry-wide issue was found in the way many modern microprocessor
designs have implemented speculative execution of instructions (a commonly
used performance optimization). There are three primary variants of the
issue which differ in the way the speculative execution can be exploited.
Variant CVE-2017-5715 triggers the speculative execution by utilizing
branch target injection. It relies on the presence of a precisely-defined
instruction sequence in the privileged code as well as the fact that memory
accesses may cause allocation into the microprocessor's data cache even for
speculatively executed instructions that never actually commit (retire). As
a result, an unprivileged attacker could use this flaw to cross the syscall
and guest/host boundaries and read privileged memory by conducting targeted
cache side-channel attacks. (CVE-2017-5715)

Note: This is the libvirt side of the CVE-2017-5715 mitigation.

Red Hat would like to thank Google Project Zero for reporting this issue.

4. Solution:

For details on how to apply this update, which includes the changes
described in this advisory, refer to:

https://access.redhat.com/articles/11258

After installing the updated packages, libvirtd will be restarted
automatically.

5. Bugs fixed (https://bugzilla.redhat.com/):

1519780 - CVE-2017-5715 hw: cpu: speculative execution branch target injection

6. Package List:

Red Hat Enterprise Linux Desktop (v. 6):

Source:
libvirt-0.10.2-62.el6_9.1.src.rpm

i386:
libvirt-0.10.2-62.el6_9.1.i686.rpm
libvirt-client-0.10.2-62.el6_9.1.i686.rpm
libvirt-debuginfo-0.10.2-62.el6_9.1.i686.rpm
libvirt-python-0.10.2-62.el6_9.1.i686.rpm

x86_64:
libvirt-0.10.2-62.el6_9.1.x86_64.rpm
libvirt-client-0.10.2-62.el6_9.1.i686.rpm
libvirt-client-0.10.2-62.el6_9.1.x86_64.rpm
libvirt-debuginfo-0.10.2-62.el6_9.1.i686.rpm
libvirt-debuginfo-0.10.2-62.el6_9.1.x86_64.rpm
libvirt-python-0.10.2-62.el6_9.1.x86_64.rpm

Red Hat Enterprise Linux Desktop Optional (v. 6):

i386:
libvirt-debuginfo-0.10.2-62.el6_9.1.i686.rpm
libvirt-devel-0.10.2-62.el6_9.1.i686.rpm

x86_64:
libvirt-debuginfo-0.10.2-62.el6_9.1.i686.rpm
libvirt-debuginfo-0.10.2-62.el6_9.1.x86_64.rpm
libvirt-devel-0.10.2-62.el6_9.1.i686.rpm
libvirt-devel-0.10.2-62.el6_9.1.x86_64.rpm
libvirt-lock-sanlock-0.10.2-62.el6_9.1.x86_64.rpm

Red Hat Enterprise Linux HPC Node (v. 6):

Source:
libvirt-0.10.2-62.el6_9.1.src.rpm

x86_64:
libvirt-0.10.2-62.el6_9.1.x86_64.rpm
libvirt-client-0.10.2-62.el6_9.1.i686.rpm
libvirt-client-0.10.2-62.el6_9.1.x86_64.rpm
libvirt-debuginfo-0.10.2-62.el6_9.1.i686.rpm
libvirt-debuginfo-0.10.2-62.el6_9.1.x86_64.rpm
libvirt-python-0.10.2-62.el6_9.1.x86_64.rpm

Red Hat Enterprise Linux HPC Node Optional (v. 6):

x86_64:
libvirt-debuginfo-0.10.2-62.el6_9.1.i686.rpm

Meltdown/Spectre; Linux on z affected?

[R P Herrold]

This is the email notification matching the Red Hat link
Neale posted a moment ago, this for their '6 series, calling
out PPC64 and s390x, and very curiously 'noarch', implying
that something ONLY in userspace needed amendment

The linked announcement quite explicitly inclides PPC64 and
s390x
https://access.redhat.com/errata/RHSA-2018:0011

-- Russ herrold

-- Forwarded message --
Date: Wed, 3 Jan 2018 19:19:13
From: Security announcements for all Red Hat products and services.

To: rhsa-annou...@redhat.com
Subject: rhsa] Important: kernel security update

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

=
   Red Hat Security Advisory

Synopsis:  Important: kernel security update
Advisory ID:   RHSA-2018:0011-01
Product:   Red Hat Enterprise Linux
Advisory URL:  https://access.redhat.com/errata/RHSA-2018:0011
Issue date:2018-01-03
=

1. Summary:

An update for kernel is now available for Red Hat Enterprise Linux 6.7
Extended Update Support.

Red Hat Product Security has rated this update as having a security impact
of Important. A Common Vulnerability Scoring System (CVSS) base score,
which gives a detailed severity rating, is available for each vulnerability
from the CVE link(s) in the References section.

2. Relevant releases/architectures:

Red Hat Enterprise Linux HPC Node EUS (v. 6.7) - noarch, x86_64
Red Hat Enterprise Linux HPC Node Optional EUS (v. 6.7) - x86_64
Red Hat Enterprise Linux Server EUS (v. 6.7) - i386, noarch, ppc64, s390x, 
x86_64
Red Hat Enterprise Linux Server Optional EUS (v. 6.7) - i386, ppc64, s390x, 
x86_64

3. Description:

The kernel packages contain the Linux kernel, the core of any Linux
operating system.

Security Fix(es):

An industry-wide issue was found in the way many modern microprocessor
designs have implemented speculative execution of instructions (a commonly
used performance optimization). There are three primary variants of the
issue which differ in the way the speculative execution can be exploited.

Note: This issue is present in hardware and cannot be fully fixed via
software update. The updated kernel packages provide software mitigation
for this hardware issue at a cost of potential performance penalty. Please
refer to References section for further information about this issue and
the performance impact.

In this update mitigations for x86-64 architecture are provided.

Variant CVE-2017-5753 triggers the speculative execution by performing a
bounds-check bypass. It relies on the presence of a precisely-defined
instruction sequence in the privileged code as well as the fact that memory
accesses may cause allocation into the microprocessor's data cache even for
speculatively executed instructions that never actually commit (retire). As
a result, an unprivileged attacker could use this flaw to cross the syscall
boundary and read privileged memory by conducting targeted cache
side-channel attacks. (CVE-2017-5753, Important)

Variant CVE-2017-5715 triggers the speculative execution by utilizing
branch target injection. It relies on the presence of a precisely-defined
instruction sequence in the privileged code as well as the fact that memory
accesses may cause allocation into the microprocessor's data cache even for
speculatively executed instructions that never actually commit (retire). As
a result, an unprivileged attacker could use this flaw to cross the syscall
and guest/host boundaries and read privileged memory by conducting targeted
cache side-channel attacks. (CVE-2017-5715, Important)

Variant CVE-2017-5754 relies on the fact that, on impacted microprocessors,
during speculative execution of instruction permission faults, exception
generation triggered by a faulting access is suppressed until the
retirement of the whole instruction block. In a combination with the fact
that memory accesses may populate the cache even when the block is being
dropped and never committed (executed), an unprivileged local attacker
could use this flaw to read privileged (kernel space) memory by conducting
targeted cache side-channel attacks. (CVE-2017-5754, Important)

Note: CVE-2017-5754 affects Intel x86-64 microprocessors. AMD x86-64
microprocessors are not affected by this issue.

Red Hat would like to thank Google Project Zero for reporting these issues.

4. Solution:

For details on how to apply this update, which includes the changes
described in this advisory, refer to:

https://access.redhat.com/articles/11258

The system must be rebooted for this update to take effect.

5. Bugs fixed (https://bugzilla.redhat.com/):

1519778 - CVE-2017-5753 hw: cpu: speculative execution bounds-check bypass
1519780 - CVE-2017-5715 hw: cpu: speculative execution branch target injection
1519781 - CVE-2017-5754 hw: cpu: speculative execution permission 

Meltdown/Spectre; Linux on z affected?

[R P Herrold]

On Thu, 4 Jan 2018, Guest, Darren wrote:

> Not sure if people have seen that attached article or heard of the 'intel' 
> chip issues from elsewhere:
> https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

The defect is that crafted code can cause hardware based
'speculative' execution' to fetch into a cache from memory
without checking (lower applicaion level) ACL rights, but then
NOT be on the 'effective' execution path followed.  If the
code path WERE on the followed execution path, ACL's would be
applied, and an access fault raised.  These exploits [at least
three modalities have been identified so far] permit bypass of
such checks

The 'fetched' and possibly sensitive, matter remains in the
cache however.  Then the contents in the cache are 'harvested'
and able to be exfiltrated

As the exploited interaction is between what hardware _can_
do, and what the OS / kernel / libraries think the hardware
SHOULD do, it is not at all clear that this will not be a
broader bug than presently known

my $0.02, but I don't see a hole in the reasoning on how to
extend it

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: In-place upgrade of RHEL 6.x to 7.x

[R P Herrold]

On Wed, 3 Jan 2018, Eric Chevalier wrote:

> > I would be interested in seeing a copy ( a private response is
> > fine) of:
> > rpm -qf `which preupg`
> > 
> > and then:
> > rpm -qi (result_from_first_command_above)

> [root@zlinux1 ~]# rpm -qf `which preupg`
> preupgrade-assistant-2.3.3-2.el6.noarch
> [root@zlinux1 ~]# rpm -qi preupgrade-assistant-2.3.3-2.el6.noarch

> Group   : System Environment/Libraries   Source RPM:
> preupgrade-assistant-2.3.3-2.el6.src.rpm

Thank you

Red Hat have not released their '2.3' series sources into 
their 'RawHide', but that 'rpm -qi ' gave me enough detail to 
partially track down the upstream, which is at:
https://github.com/phracek/preupgrade-assistant

There are some rather obvious and stale bugs needing fixes in 
the GitHub version 'issues' list

If you have a TAM, I would involve that person; alternatively 
assuming you may have RHEL subscription to get access to some 
'side channels', I would open a ticket with Red Hat.  Please 
also ask then to release into 'RawHide' the present: 
preupgrade-assistant

which seem to be:
 GPLv3+

but at the later NEVR mentioned 
(preupgrade-assistant-2.3.3-2.el6.src.rpm)

Thank you

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: In-place upgrade of RHEL 6.x to 7.x

[R P Herrold]

On Wed, 3 Jan 2018, R P Herrold wrote:

> Fedora space, called, respectively: preupgrade and 
> preupgrade-assistant.  ... 

I looked at the 'preupgrade' (RHEL oriented) sources, and 
there is a missing dependency, getting the package to install 
once built, on '7

I solved that with a local 'carry forward' port out of '6 of 
'anaconda-yum-plugins'

  Installing : 1:anaconda-yum-plugins-1.0-5.1.orc7.noarch
  Installing : python-deltarpm-3.6-3.el7.x86_64  
  Installing : createrepo-0.9.9-28.el7.noarch
  Installing : preupgrade-1.1.9-1.orc7.noarch  

Then firing it up, I get this message:

please give a release to try to pre-upgrade to
valid entries include:
   "Fedora 16 (Verne)"
   "Fedora 15 (Lovelock)"
   "Fedora 13 (Goddard)"
   "Fedora 11 (Leonidas)"
   "Fedora 12 (Constantine)"
   "Fedora 17 (Beefy Miracle)"
   "Fedora 14 (Laughlin)"
   "Fedora 10 (Cambridge)"


Checking my handy decoder chart, I see:

 #   Fedora 12, 13   → Red Hat Enterprise Linux 6   
f12 f13 May 25 2010 1302 days

 #   Fedora 19, 20   → Red Hat Enterprise Linux 7   
f19 f20 Dec 17 2013

so, not 'long enough' coverage there to get forward to when '7 
was forked out of Fedora for stabilization

...

Trying to build preupgrade-assistant was even less useful, as 
it does not pick up and start until F 23

The Fedora version even with the '7 fork was: 
preupgrade-1.1.4-1.fc13.src.rpm

and when built and installed, that tosses a Python 2 usage 
error when starting

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

In-place upgrade of RHEL 6.x to 7.x

[R P Herrold]

On Wed, 3 Jan 2018, Eric Chevalier wrote:

> We are currently running RHEL 6.9 on top of z/VM. We are contemplating
> an upgrade to RHEL 7 in order to support Spectrum Protect 8.1.4.
>
> RHEL supposedly supports an in-place upgrade from the latest version of
> RHEL 6.x to 7, but I'm coming across discussions suggesting that the
> in-place upgrade path is not without serious pitfalls. I've run the
> upgrade advisor ("preupg") on one of our RHEL6 systems, the results
> suggested a great deal of manual work would be required to complete the
> upgrade. Our alternative is to create a new, clean RHEL 7 system and
> then migrate Spectrum Protect.

I don't see such a binary 'preupg' in a base RHEL
distribution.  There are a couple of attempts in RHEL and in
Fedora space, called, respectively: preupgrade and
preupgrade-assistant.  I know that the CentOS rebuild project
wiki recently (within the last two months) added BIG RED
WARNINGS about being stale, bit-rotted, and not usable, to
their former outline respecting moving across Version major
releases


As you note the 'support' and scope of work with 'across major
Version' of the Red Hat product is at best, a limited form of
support

I would be interested in seeing a copy ( a private response is
fine) of:
rpm -qf `which preupg`

and then:
rpm -qi (result_from_first_command_above)

just to run down the sources in play at your shop


I have done such 'cross major Version' moves, with 'walking'
in a new kernel and glibc and python and rpm, and reboots to
get new libraries, etc in play; but the process is not clean
and not for the novice.  I knew I had a full set of tested
backups and a willingness to revert to them and start again
(and indeed had to do so)


There is no doubt in my mind that it will be less stressful,
and be done sooner, deploying a new '7' box and configuring it

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Ethernet/VSwitch woes

[R P Herrold]

On Mon, 13 Nov 2017, Frank M. Ramaekers wrote:

> Okay, I have a Fedora release 23 install.  Everything work
> greatwell that's until I reboot (re-IPL).  There is an
> inconsistency in the initialization of the Ethernet
> interfaces:

> 3)  Both interfaces come up normally:

> ifconfig
> enccw0.0.0600: flags=4163  mtu 4096
> inet 10.1.20.84  netmask 255.255.0.0  broadcast 10.1.255.255
> RX packets 1542  bytes 182508 (178.2 KiB)
> RX errors 0  dropped 98  overruns 0  frame 0
> TX packets 46  bytes 4642 (4.5 KiB)
> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

> enccw0.0.0700: flags=4163  mtu 4096
> inet 192.168.199.84  netmask 255.255.255.0  broadcast 192.168.199.25
> RX packets 0  bytes 0 (0.0 B)
> RX errors 0  dropped 0  overruns 0  frame 0
> TX packets 26  bytes 2962 (2.8 KiB)
> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

> I'm not seeing any differences in the startup messages, so I'm a bit puzzled.
> (I also have a SUSE-SLES12 that doesn't experience this behavior)

Case 3 has a very high 'drop' rate, when none would be
expected on '0600'; and no RX packets (no arp, no replies --
nothing) on '0700'

That kind of jumps out at me, and in a physical network, I
would expect that the patch-bay was not properly plugged in.
Dunno here

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: RHEL 7.4 - Difficulties

[R P Herrold]

On Tue, 7 Nov 2017, Mark Post wrote:

> >>> On 11/7/2017 at 12:36 PM, R P Herrold <herr...@owlriver.com> wrote:
> > I don't understand what you are seeking as a change from Red
> > Hat here, Mark
>
> I'm not seeking any change from Red Hat, just telling the OP
> that unless that change happens (and I'm pretty sure it will
> not), he's going to have to keep doing this (or whatever
> might be preferable) as long as he wants to keep the
> "old/traditional" interface names of eth?.

* nod *  Okay

I was unsure if you felt that there was some approach on your
$EMPLOYER's side that RHT was 'missing a bet' in not
documenting how to address, and was planning to file with them
any RFE, if that were the case

Thank you

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: RHEL 7.4 - Difficulties

[R P Herrold]

I guess I 'lost the thread' here.   There is no
/etc/sysconfig/grub in s390x in a RHEL 7 sources rebuild
default install (as with our ClefOS).

Here is a long 'point by point' summation, and file and
contents dump, for a checklist.  As noted, I have not had to
trace out how dracut / grubby is 'massaging things, but most
of the rest is from a dead plain simple RHEL 7.4 sources
rebuild install (ClefOS 7)

1. Editing kernel boot time parameters is done in grubby /
dracut , and as it is s390x. the zipl settings in the 'conf'
files contained in: s390utils-base

[root@lclef01 network-scripts]# grubby --info=` grubby \
--default-kernel `
index=0
kernel=/boot/vmlinuz-3.10.0-693.2.2.el7.s390x
args="crashkernel=auto rd.dasd=0.0.01b0 cio_ignore=all,!condev \
LANG=en_US.UTF-8"
root=/dev/disk/by-path/ccw-0.0.01b0-part3
initrd=/boot/initramfs-3.10.0-693.2.2.el7.s390x.img
title=3.10.0-693.2.2.el7.s390x
[root@lclef01 network-scripts]#

[I added the  '\" continuation in the prior paste to show
that is all one line.]


2. One amends what 'grubby' uses thus:
grubby --update-kernel=ALL --remove-args=quiet

or:
 grubby --update-kernel=ALL --args=quiet


3. I _believe_ but cannot demonstrate that 'grubby' is parsing
kernel 'parameter' lines not from a SPOT -- single point of
truth', but rather merging several sources, in the collection
of:
- reading and parsing prior state

- in the case of x86, from parsing:
/etc/sysconfig/grub
[NOT in play on s390x]

- in the case of s390x, from parsing:
/etc/zipl.conf

---

4. Then running an architecture specific command:

for x86: grub2-mkconfig -o /etc/grub2.cfg

for s390s, using helper scripts such as: znetconf
(which detects, and 'properly' sets up network devices)
and 'mkinitrd', to get to a valid 'initrd.

5. That initrd may be inspected thus:
/usr/bin/lsinitrd | less

where one finds scripts, modules, udevd rules, and binaries
specific to 'Z', including:
zfcp
znet
/usr/lib/dracut/hooks/cmdline/30-parse-zfcp.sh
/usr/lib/dracut/hooks/cmdline/30-parse-dasd.sh
/usr/lib/dracut/hooks/cmdline/31-parse-dasd-mod.sh

/usr/lib/modules/3.10.0-693.2.2.el7.s390x/kernel/drivers/s390/block/dasd_eckd_mod.ko

/usr/lib/modules/3.10.0-693.2.2.el7.s390x/kernel/drivers/s390/block/dasd_mod.ko
/usr/lib/udev/rules.d/56-dasd.rules
/usr/lib/udev/rules.d/59-dasd.rules
/usr/sbin/dasd_cio_free
/usr/sbin/dasdconf.sh
/usr/sbin/dasdinfo
/usr/sbin/normalize_dasd_arg
/usr/sbin/zfcp_cio_free
/usr/sbin/zfcpconf.sh
/usr/sbin/znet_cio_free

6. That is, this is not a black art in play, but a customary
RHT approach to Linux boot matter, with the needed extensions
for the architecture. One can 'trace through' when there is a
problem, and see what is happening


[root@lclef01 etc]# uname -a
Linux lclef01.lf-dev.marist.edu 3.10.0-693.2.2.el7.s390x #1
SMP Sat Sep 16 05:14:53 EDT 2017 s390x s390x s390x GNU/Linux
[root@lclef01 etc]# rpm -qa | grep grub
grubby-8.28-23.el7.s390x
[root@lclef01 etc]# rpm -ql grubby | grep "grub$"
[root@lclef01 etc]#

[root@lclef01 etc]# rpm -ql s390utils-base | grep "conf$"
/etc/dasd.conf
/etc/rc.d/init.d/dumpconf
/etc/sysconfig/dumpconf
/etc/zfcp.conf
/etc/zipl.conf
/sbin/qethconf
/sbin/znetconf

[root@lclef01 etc]# cat /etc/zipl.conf
[defaultboot]
defaultauto
prompt=1
timeout=5
default=3.10.0-693.2.2.el7.s390x
target=/boot
[3.10.0-693.2.2.el7.s390x]
image=/boot/vmlinuz-3.10.0-693.2.2.el7.s390x
parameters="root=/dev/disk/by-path/ccw-0.0.01b0-part3
crashkernel=auto rd.dasd=0.0.01b0 cio_ignore=all,!condev
LANG=en_US.UTF-8"
ramdisk=/boot/initramfs-3.10.0-693.2.2.el7.s390x.img
[linux]
image=/boot/vmlinuz-3.10.0-693.el7.s390x
ramdisk=/boot/initramfs-3.10.0-693.el7.s390x.img
parameters="root=/dev/disk/by-path/ccw-0.0.01b0-part3
crashkernel=auto rd.dasd=0.0.01b0 cio_ignore=all,!condev
LANG=en_US.UTF-8"
[linux-0-rescue-cc310857ab8f44e8b0853bd600c93306]

image=/boot/vmlinuz-0-rescue-cc310857ab8f44e8b0853bd600c93306

ramdisk=/boot/initramfs-0-rescue-cc310857ab8f44e8b0853bd600c93306.img
parameters="root=/dev/disk/by-path/ccw-0.0.01b0-part3
crashkernel=auto rd.dasd=0.0.01b0 cio_ignore=all,!condev"
[root@lclef01 etc]#


7. Focusing in more closely, the mentioned 'condev' entries
are present by default:

[root@lclef01 etc]# cat /etc/zipl.conf | grep "condev"
parameters="root=/dev/disk/by-path/ccw-0.0.01b0-part3
crashkernel=auto rd.dasd=0.0.01b0 cio_ignore=all,!condev
LANG=en_US.UTF-8"
parameters="root=/dev/disk/by-path/ccw-0.0.01b0-part3
crashkernel=auto rd.dasd=0.0.01b0 cio_ignore=all,!condev
LANG=en_US.UTF-8"
parameters="root=/dev/disk/by-path/ccw-0.0.01b0-part3
crashkernel=auto rd.dasd=0.0.01b0 cio_ignore=all,!condev"
[root@lclef01 

Re: P7zip for RHEL 7 s390x

[R P Herrold]

On Thu, 2 Nov 2017, Davis, Larry (National VM Capability) wrote:

> Thank You this is great help

you are welcome

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: P7zip for RHEL 7 s390x

[R P Herrold]

responding to myself:

On Thu, 2 Nov 2017, R P Herrold wrote:

> https://download.sinenomine.net/epel/epel7/s390x/
>
> mid-page along with some other p7zip adjuncts (GUI, etc)

there is a later one actually -- p7zip-16.02-2.el7.s390x
which installed trivially for me with no dependencies

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: P7zip for RHEL 7 s390x

[R P Herrold]

On Thu, 2 Nov 2017, Neale Ferguson wrote:

suggested rebuilding from sources -- we've done that

Davis, Larry earlier:
> >I am searching for p7zip for processing large files on RHEL 7 and I can
> >find the RPM files for Fedora "p7zip-16.02-6.fc28.s390x.rpm" can I

We have it in ClefOS already which will work fine without a
rebuild from sources

p7zip-16.02-1.el7.s390x

https://download.sinenomine.net/epel/epel7/s390x/

mid-page along with some other p7zip adjuncts (GUI, etc)

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: TERM=linux instead of TERM=dumb

[R P Herrold]

On Fri, 20 Oct 2017, Dimitri John Ledkov wrote:

> Why do you want to use TERM=dumb instead of Linux?

> I've tried proposing to systemd to not use color in LPAR/ZVM modes,
> but that was rejected see

> https://github.com/systemd/systemd/issues/3115

ehh?

This (accepted) patch appear to accept and pass through any
kernel argument line setting for 'TERM='

https://github.com/systemd/systemd/commit/32391275c02715f76232128c49b19bb619cd9463

That said, I do not hold the belief that the kernel parameter
line presently supports passing in a 'TERM=blah' value

see in the kernel sources file:
kernel-parameters.txt

which has no (present) mention of handling such

https://raw.githubusercontent.com/torvalds/linux/master/Documentation/admin-guide/kernel-parameters.txt

Also local ditribution packagers may silently amend that
list and cause certain lines to NOT be includable ...
audit=1

is an example wihch I have encountered in ClefOS (the s390x
Red Hat derived distribution which SNA and I worked up) space

I would suspect the place to over-ride such was down in the
/etc/profile.d/

snake's nest of files.  I have poked Rich T to lend a SUSE
s390x instance available to me, but that it where I would look

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: OT: Is there a setting that can prevent trash in the LINUX-390 archives?

[R P Herrold]

On Thu, 8 Jun 2017, Mark Post wrote:

> I'm not aware of any email client that will pick and choose
> which sections of an email are base64 and decode them on the
> fly.  I suspect the solution is not going to be on the
> LISTSERV side, but on each poster's client.  Which makes it
> extremely unlikely for a solution to be found.

assuming the MIME headers are intact, Alpine will.  That said,
I also feel my inbound email through a 'procmail' based
decoding front end.  There was formerly a general 'mimedecode'
package around, but it too is fragile.  'sniffing' the
headers, and feeding content through openssl can also handle
the decodes, but it is fugly

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: EPEL

[R P Herrold]

On Tue, 14 Feb 2017, Paul Flint wrote:

> Quite a collection and contribution.  I presume a spell checker is included in
> the Extra Packages for Enterprise Linux?

actually the base OS has a full suite of spelling tools

[herrold ~]$ rpm -qa \*spell\* | grep -v devel
hspell-1.2-6.el7.x86_64
gtkspell-2.0.16-8.el7.x86_64
aspell-en-7.1-5.el7.x86_64
hunspell-en-US-0.20121024-5.el7.noarch
hunspell-1.3.2-15.el7.x86_64
gtkspell3-3.0.3-4.el7.x86_64
aspell-0.60.6.1-9.el7.x86_64
[herrold ~]$

There has been some churn in what the spelling tool is CALLED,
however --- GNU aspell is the replacement for the former
ispell, but it seems to drag in other parts, so I list what is
present on my machine

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Typescript on zLinux?

[R P Herrold]

On Tue, 10 Jan 2017, Michael MacIsaac wrote:

> Has the typescript environment been ported to zLinux (superset of
> JavaScript that 'transpiles' to JavaScript)?

I see it in Fedora

/var/ftp/pub/nfs/mirror/redhat/fedora/24/os/SRPMS/n/nodejs-typescript-1.4.1-3.fc24.src.rpm

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Docker on Z

[R P Herrold]

On Tue, 25 Oct 2016, PHILIP TULLY wrote:

> We are looking to implement Docker on Z, as we have begun the testing
> part of the issue is to be able to grow a docker engine and growing it
> dynamically based on it's current needs especially when a node in the
> Docker cluster fails.
>
> So the question is does anyone see a way for the VM system to see the
> memory resource grow, which would allow me to add more dynamically.

I thought one point of Docker was to have 'fast to spin up'
instances, ready to spin up, which then pulled in ephemeral
data from a back end persistent store, so that a swarm of them
handled load spikes, and once the spike passes, that the
excess units are shut down

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

HyperPAV boot issues on ClefOS 6.7

[R P Herrold]

On Tue, 24 May 2016, Morris, Kevin J. (RET-DAY) wrote:

> We have ~20 zLinux systems running in their own LPARs (no zVM) all on RHEL 
> 6.4 without any issues over the past year.  All systems were rebooted weekly, 
> again without any issues.

Is the reboot being trigerred internally (a cron process, or
external process sshing in and sending the reboot sequence),
or via an external signal (I am wondering if a too fast
shutdown before HyperPAV state has synced, is in play)

> We are in the process of migrating them to ClefOS 6.7 and have started to 
> experience random errors with the file system check at reboot essentially 
> causing the box to hang until someone manually intervenes. The following 
> messages are displayed on the console:
> *** An error occurred during the file system check.

This is usually from 'finding' an un-removed (from the prior
session) /.autofsck file remnant.  trace the shutdown and
startup code in /etc/init.d/ via:

cd /etc/init.d
grep fsck *

to see the scripts in play under ClefOS 6 series.  When those
don't get removed and the filesystem synced to get the updates
done, spurious fsck's get requested.  It is my understanding
that 'under the hood, the HyperPAV facility seeks to
anticipate such operations, and it may just be 'not enough'
settling time

If it is the non-root ("/") partition which is being 'fsck'ed
it may be worth adding a k99 step, blocking on a umount of
such.  It would certainly be 'harmless' to add in any case
partition

https://bugzilla.redhat.com/show_bug.cgi?id=738870 is
suggestive that detection of non-sync's states had been a
topic

> If I remove the PAV aliases from /etc/dasd.conf, the reboot problems appear 
> to go away -- I can reboot 50 times without an issue.

Thus suggesting HyperPAV quite strongly

> Obviously, we want to use HyperPAV, so simply removing the aliases isn't 
> really a "fix".
> Can anyone offer any advice on how solve this problem or further debug the 
> issue.
> Something apparently changed between RHEL 6.4 and ClefOS (RHEL) 6.7.

Kind of a big step in terms of time between 6.4 and 6.7; but
the suggestions above, along with perhaps adding remote
syslogging, to permit capturing early 'dmesg' content, and
possibly late messages, come to mind as places to start

Thanks for trying ClefOS -- I appreciate the report

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: SLES SP4 and use of the openCryptoki package

[R P Herrold]

On Tue, 3 May 2016, Mark Post wrote:

> Well, we can't include what IBM doesn't provide us for
> inclusion.  I never even heard of this RPM until today.
... [not a] very good option since so few people read the
> release notes or pop-ups.

it seems to be the topic of a later supplementation to that SP

https://www.suse.com/support/update/announcement/2016/suse-ou-20160156-1.html

More troubling were all the stray (and conflicting) versions
installed -- the package manager (RPM) should have (and absent
someone 'messing with it' will) remove obsolete prior versions

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: ? FTP permissions on FEDORA ?

[R P Herrold]

On Fri, 25 Mar 2016, Tom Huegel wrote:

> Thank you Grzegorz that information is most appreciated.
>  I am sure that would have been my next problem.
>
> Even after your suggested changes I still get this message..

It might make sense to use lftp or such and confirm that you
can addess the content (do the CD and read the directory)
manually before trying an install

Please place SELinux into permissive mode generally on the
FTP server where you have loop mounted the ISO; as I recall,
there were some problems with accessing loop-mounted content
via FTP in some Fedora versions as well

it is possible to 'rsync' the ISO off, into /var/ftp/whatever/
, and do a selinux relabel as well
restorecon -rv /var/ftp

or just allow the FTPD general access into system

setsebool -P allow_ftpd_full_access 1

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

ClefOS - Server with GUI

[R P Herrold]

On Wed, 2 Mar 2016, Frank M. Ramaekers wrote:

> I'm attempting to (re)install ClefOS (7.1.1503) and selected "Server
> with GUI", but it is failing with:

This is probably a problem in the installation package set
available.  I don't recall that we expressly test and verify
that there is local 'package closure' for each of the
installation variants.  If there is a network up and running,
if DNS is working, and if the fates smile, 'holes' in a local
package set should be supplemented from the remote 'yum'
archive.  But this can be dicey

The absence of a dependency in  the libreoffice chain is a
problem and I'll do some testing

Probably the best workaround is to do a minimal install, and
then use the 'yum group' commands: yum group list, and
friends, in ClefOS 7, and install either in a %post stanza if
using kickstart in anaconda, or manually at the command line

As to manually managing the firewall chain in ClefOS 7 ,
there is a workaround to get it back to TUI friendly, and more
like the earlier Red Hat derived 'iptables' method:

yum -y install iptables-services
chkconfig firewalld off
chkconfig iptables on
#   save the existing ruleset for iptables to use
service firewalld save
service firewalld stop
service iptables start

There are like TUI rule management capabilities for the
firewalld package, but they seem less direct, and less
intuitive to me

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: RPM build question

[R P Herrold]

On Thu, 4 Feb 2016, Mark Post wrote:

> Do you have /usr/bin/python3 on your system?  If so, you'll
> likely have to remove it until after the build is finished.
> I've found that even building packages without RPM sometimes
> necessitates this because things like ./configure find
> packages that I don't want used.

perhaps, but in a clefos 7.x environment, those versions
should only sneak in if the 'epel' derived packages are
present
python3-pkgversion-macros.noarch
python34.%{arch}

The 'auto-tools' ./configure in a 'mock' build environment
should be tightly constrained against such errors

I note also the presence of:
python34-mock.noarch
python34-setuptools.noarch
python34-tools.%{arch}

and any of those might also 'pollute' the rpmbuild
environment.  But I suspect that these are not in play so much
as an unintended 'back-leak' in the rpm build macros has a
'python3' expansion.  In recent weeks, on the rpm-list for
development of rpm, there has been some agitation out the
folks out on the 'Fedora' bleeding edge to re-work 'old'
macros, and there has been essentially zero concern for such
trivia as backward compatibility or testing against
'enterprise' products.  This may bave polluted the mock
carry-forward of the relevant macros

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Curious about crash.

[R P Herrold]

On Wed, 16 Dec 2015, John McKown wrote:

> ​Or, as one co-worker tells it, they have their CEC up against the back
> wall. Unbeknownst to them, on the other side of the wall is a mega-Gauss
> electromagnet. ​Magnet on, CEC fails.

one of our site design rules is to never wrap the Token Ring 
network cables around the cyclotron  ;)

-- R

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Curious about crash.

[R P Herrold]

On Wed, 16 Dec 2015, Tom Huegel wrote:

> Right the kernel appears to be different.

* nod *

Next diagnostic step would be a reinstall of a registered
system, and then after a yum update, but before the reboot,
please try the code below, for the phase one to chainload
into, to see if it can 'solve' the path

> > mv grub.cfg grub.cfg-BAK
> > grub2-mkconfig -o /boot/grub2/grub.cfg

if that works I would be interested in a comparison of the BAK
file and its successor

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Curious about crash.

[R P Herrold]

On Wed, 16 Dec 2015, Alan Altmark wrote:

> On Wednesday, 12/16/2015 at 02:48 GMT, Tom Huegel 
> wrote:

> > Now the registered machine fails to boot, the other one works fine.
>
> A gamma ray collided with a 1 and knocked it over, turning it into a 0.
> That's the only explanation I can think of.  I used to think it was
> sunspots or coronal mass ejections, but I've moved on.

Assumedly the non-registered machine is still running the
older kernel (please check which kernals are installed thus:
rpm -qa kernel\*
)

As such mkinitrd (which seems to be failing, perhaps due for a
improperly specified path to an initrd, was in play (per the
earlier message quoted)

I have found 'grub2' and grubby, to be quite sensitive to the
configuration file it is handed.  There are 'order issues' on
what needs to appear before and after other items, not well
documented.  From my notes:

The following will generate the  correct grub.cfg file
( /boot/grub2/ is RHEL / ClefOS 7 and later ... )

cd /boot/grub2/
mv grub.cfg grub.cfg-BAK
grub2-mkconfig -o /boot/grub2/grub.cfg

but sadly the 'fix' does not persist when a new kernel is
installed. not sure why as I have been off solving other
issues

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Error_139=94?=

[R P Herrold]

On Mon, 20 Jul 2015, Vitale, Joseph wrote:

 ./configure
 make

 gcc -pthread -fPIC -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes 
 -Werror=declaration-after-statement -I/usr/local/ssl/include -I./Include -I. 
 -IInclude -I/usr/local/include
 -I/xjp/Python-3.4.3/Include -I/xjp/Python-3.4.3 -c 
 /xjp/Python-3.4.3/Modules/_ssl.c -o 
 build/temp.linux-s390x-3.4/xjp/Python-3.4.3/Modules/_ssl.o
 gcc -pthread -shared 
 build/temp.linux-s390x-3.4/xjp/Python-3.4.3/Modules/_ssl.o 
 -L/usr/local/ssl/lib -L/usr/local/lib -lssl -lcrypto -o 
 build/lib.linux-s390x-3.4/_ssl.cpython-34
 m.so

 /bin/sh: line 6: 48734 Segmentation fault  (core dumped) CC='gcc 
 -pthread' LDSHARED='gcc -pthread -shared  ' OPT='-DNDEBUG -g -fwrapv -O3 
 -Wall -Wstrict-prototypes' _TCLTK_I
 NCLUDES='' _TCLTK_LIBS='' ./python -E ./setup.py $quiet build
 make: *** [sharedmods] Error 139

The setup.py is failing down in a section which seemingly is
set to run '$quiet'ly.  It may make sense to over-ride this so
you can see where it is failing

When building with either tk or tcl, usually both -devel
libraries are needed. tk-devel and tcl-devel

Python-3 is usually built and installed 'alongside' the
python-2.6 in a RHEL 6 environment (there are deep
dependencies for that 2 series version of Python throughout
the environment of RHEL 6.  The SCL' project which some Red
Hat engineering folks somes to mind.  I see:
/var/ftp/pub/nfs/mirror/centos/all/6/SRPMSonly/6.5/SCL/\
Source/SPackages/python33-python-3.3.2-7.el6.centos.alt.src.rpm

It might make sense to open a request with your TAM

which I will take a run at shortly;  I need to find the
package providing the 'scl_prefix' rpmbuild macro ...

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

IP Sprayer

[R P Herrold]

On Thu, 12 Mar 2015, Stewart, Lee wrote:

 Does anyone know of an IP “sprayer” for Linux on Z?  (To
 send arriving requests on to one of several servers, round
 robin or load balanced.)

nginx as the 'go to' tool?  Certainly in the RHEL space; also
squid as a reverse proxy depending on the protocols needed

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Single User mode Linux Guest

[R P Herrold]

On Thu, 19 Feb 2015, Michael MacIsaac wrote:

 Which Linux are you using?

 I tried on SLES, but could not get logged in as root without the password.
 In The Virt'n Cookbook section 26.1.1 Enter single user mode, it states:
 In single user mode, you are logged in as the root user.

 But this does not seem to be the case (who wrote that book? - somebody
 better fix it :))

I have seen a similar prompt on RHEL 7 under systemd when
trying to enter single user mode.  a security matter, I assume

I had to work around the matter by loop-mounting the image and
blanking the hashed entry for root in /etc/shadow

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: vmcp on RHEL 7?

[R P Herrold]

On Thu, 9 Oct 2014, Rick Troth wrote:

 Good practice to ignore certain errors from 'modprobe', and this is a
 prime example.

?? 'Good practice to ignore' ??

 So if you happen to have a shell script that does a
 'modprobe vmcp' before doing a 'vmcp' command, it should re-direct
 stderr (of the first part) to /dev/null.

?? !!

 If there's an actual error, the
 latter command will fail and will clue the user that something's wrong.
 Think about it.

Why burden the administrator with needing to understand the
politics of what the initscript writer should be doing?

If I understand what you are saying, I think you are off base.
I cannot really see that it ever makes sense to hide debugging
information, rather than writing tests to catch and use the
knowledge that message imparts

If a given facility is in a module
lsmod [modulename]
will inventory if a given module is
loaded without the need for:
2 /dev/null
quieting

If a given facility is no longer a module, one can also see
that with it is absent:
depmod -a -n -v | grep -c (modulename)
which will return a value of zero when it is built in, and
non-zero when it is a module

('find' on the /lib/ hierarchy will also do so, but depmod is
smart enough to only look at the modules relevant to the
running kernel)

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

RHEL 7 installer does not format DASD?

[R P Herrold]

On Wed, 17 Sep 2014, Michael MacIsaac wrote:

 It would seem this is the same behavior (coughBUGcough:)) as the RHEL 6
 installer (sigh ...).  I guess the good news is that you can then go back
 to the installer after the dasdfmt and it finds the free disk space.

it is only a bug to the Anaconda team, if you file it, of
course

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Exited my PuTTY session while signed on as INSTALL during initial z/Linux install

[R P Herrold]

On Fri, 29 Aug 2014, Martin, Terry Contractor wrote:

 Any suggestions on how to get back to where I was yesterday?

a reconnect to the VNC session (if specified -- it is the
easiest way, but TUI only is also supported) should be
possible; otherwise Anaconda does not run a listening daemon
for TUI RE-logins, that I know of

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: VNC JavaSecurity Error

[R P Herrold]

On Tue, 26 Aug 2014, Ihno Krumreich wrote:

 On Tue, Aug 26, 2014 at 10:48:35AM +, Walters, Gene P wrote:

  bring up a web page and go to the new instance to start a
  VNC session, it tells me that my security settings wont
  let me run the old version of Java that is being
  downloaded from the VNC server(the new Linux instance).

We ship a Java based VNC client, and have encountered problems
with:
- the Code Signing of the .JAR file had expired, and
so a local Java installation refused to run it, deeming it
insecure. Solution was to update what we shipped with a more
corrent copy
- the Java on the local machine, which was being
started by the browser, was 'stale' and had been updated
upstream; Solution there was an update of that Java (This
especially seen on OS/X units)
- the Code Signing key used to sign the .JAR was
counteresigned by a CA (Certificate Authority) not known to
the local Java installation.  Solution was to add that CA's
'chain of trust' into the local ancillary install for the
local Java install

Reading the messages closely is needed, to understand what is
in play

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: openssl CA certificate maintenance

[R P Herrold]

On Mon, 14 Jul 2014, Alan Altmark wrote:

 I'm not concerned about the format of the files, but how you
 and/or your Linux admins like to manage them, particularly
 in light of the fact that the bundles of well-known CAs is
 updated from time to time.

We are researching / testing in this space, as Oracle has
decided to only honor content .jar executables 'code signing'
signed by 'yet another' clutch of CA's not including the one
we prefer and use

The Mozilla.org folks have their (different) rules for
inclusion in their base bundle as well

And I saw a note that Google / Chrome had decided to restrict
all but eight or nine domains compromised after a secondary
Indian governmental CA incautiously signed several CSR's
purporting to be, but not actually from Google ...

And my personal long-standing desire to be able to inject at
our boundry 'squid' proxyies, a local CA wildcard certificate
so all interior content is retrieved and proxyable over SSL
only

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Setting up SSL keys and certificates; was: Re: EXTERNAL: Re: vsftpd

[R P Herrold]

/CN=mail.iwaynet.net/emailAddress=doma...@781resolution.com
   i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate
Signing/CN=StartCom Class 2 Primary Intermediate Server CA
-BEGIN CERTIFICATE-
MIIHuDCCBqCgAwIBAgIDAQe+MA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJ
 ...
D9f45J03P3Ln0Vura31pJ3KWCLyzNhXwLjbhbXay97gO2xuBKmCI+Kmp3DUIXpSl
PZC06GSzYAJnU2nK
-END CERTIFICATE-
 1 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate
Signing/CN=StartCom Class 2 Primary Intermediate Server CA
   i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate
Signing/CN=StartCom Certification Authority
-BEGIN CERTIFICATE-
MIIGNDCCBBygAwIBAgIBGjANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEW
 ...
0Y+NWZP8P3PXLrQsldiL98l+x/ydrHIEH9LMF/TtNGCbnkqXBP7dcg5XVFEGcE3v
qhykguAzx/Q=
-END CERTIFICATE-
 2 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate
Signing/CN=StartCom Certification Authority
   i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate
Signing/CN=StartCom Certification Authority
-BEGIN CERTIFICATE-
MIIHyTCCBbGgAwIBAgIBATANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEW
 ...
NOsF/5oirpt9P/FlUQqmMGqz9IgcgA38corog14=
-END CERTIFICATE-
---
Server certificate
subject=/description=6UU5cs40q72hPkRS/C=US/ST=Ohio/L=Columbus/O=781
Resolution,
LLC/CN=mail.iwaynet.net/emailAddress=doma...@781resolution.com
issuer=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate
Signing/CN=StartCom Class 2 Primary Intermediate Server CA
---
Acceptable client certificate CA names
/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate
Signing/CN=StartCom Class 2 Primary Intermediate Server CA
/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate
Signing/CN=StartCom Certification Authority
/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate
Signing/CN=StartCom Class 1 Primary Intermediate Client CA
/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate
Signing/CN=StartCom Class 1 Primary Intermediate Server CA
/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate
Signing/CN=StartCom Class 2 Primary Intermediate Client CA
/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate
Signing/CN=StartCom Class 3 Primary Intermediate Client CA
/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate
Signing/CN=StartCom Class 3 Primary Intermediate Server CA
/C=IL/O=StartCom Ltd./OU=StartCom Certification
Authority/CN=StartCom Extended Validation Server CA
---
SSL handshake has read 7667 bytes and written 302 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol  : TLSv1
Cipher: DHE-RSA-AES256-SHA
Session-ID:
BFE825275B1E0C6097C77A63DAAC8E2219D8CE3C394D4F0F7ADEAD36C0EC37F0
Session-ID-ctx:
Master-Key:
CDCF79BC50295CA239D9B42F0DA6D54F8E4A4990BD5D641BEBA7D2D77099ADE30CE3C2C5C22D4EB35E4E70FB8AAA81B0
Key-Arg   : None
Krb5 Principal: None
Start Time: 1399396761
Timeout   : 300 (sec)
Verify return code: 0 (ok)
---
250 HELP
ehlo asdf
250-mail.iwaynet.net Hello localhost.localdomain [127.0.0.1],
pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE 35882577
250-DSN
250-ETRN
250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN
250-DELIVERBY
250 HELP
quit
221 2.0.0 mail.iwaynet.net closing connection
closed
[root@mail certs]#


9.  Compare, testing with telnet, which will show the
STARTTLS
availability, but does not dig further down

[root@mail certs]# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mail.iwaynet.net ESMTP Sendmail 8.13.8/8.13.8; Tue, 6 May
2014 13:28:53 -0400
ehlo asdf
250-mail.iwaynet.net Hello localhost.localdomain [127.0.0.1],
pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE 35882577
250-DSN
250-ETRN
250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN
250-STARTTLS
^ this line is present with naiive clients
250-DELIVERBY
250 HELP
quit
221 2.0.0 mail.iwaynet.net closing connection
Connection closed by foreign host.
[root@mail certs]#


Hope these notes help.  They are the product and distillation
of much research and testing

-- Russ herrold

--
end
==
 .-- -... ---.. ... -.- -.--
Copyright (C) 2014 R P Herrold
  herr...@owlriver.com
   My words are not deathless prose,
  but they are mine.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

RPH bugtraq] CVE-2014-2845 - Cyberduck (Windows): Failure validating some certificates (using FTP-SSL) with untrusted root certificate authority (fwd)

[R P Herrold]

After my post about TLS certificate setup, I see that the
nominally capable clients need some work as well

Subject: Setting up SSL keys and certificates; ...

- R

-- Forwarded message --
Date: Tue, 6 May 2014 05:22:44
From: Micha Borrmann micha.borrm...@syss.de
To: bugt...@securityfocus.com
Subject: bugtraq] CVE-2014-2845 - Cyberduck (Windows): Failure validating some
certificates  (using FTP-SSL) with untrusted root certificate authority

Advisory ID: SYSS-2014-004
Product: Cyberduck
Affected Version(s): 4.4.3 (14140) (Windows only)
Not Affected Versions(s): 4.4.3 (14140) and 4.2.1 (9350) (both OS X
10.9.2)
Tested Version(s): 4.4.3 (Windows 7 32 bit and Windows 8.1 64 bit)
Vulnerability Type: X.509 validation
Risk Level: Medium
Solution Status: Fixed
Vendor Notification: 2014-04-08
Solution Date: 2014-04-10
Public Disclosure: 2014-05-06
CVE Reference: CVE-2014-2845
Author of Advisory: Micha Borrmann (SySS GmbH)

Overview:
Cyberduck (Windows versions only) accepts X.509 server certificate
from any CA, also if they are not in the certificate store and not
sent from the FTP server; only self-signed certificates are not accepted.

Vulnerability Details:
A user can not recognize an easy to perform man-in-the-middle attack,
because the client does not validate the certificate chain of the
servers X.509 certificate. In a networking environment that is not
trustworthy, like a wifi network, using FTP AUTH TLS with Cyberduck
the servers identity can not be trusted.

Proof of Concept (PoC):
With OpenSSL generate a key for a CA and for the server and create the
certificates:

openssl genrsa -out ca4096.key 4096
openssl genrsa -out 2048.key 2048
chmod 400 *.key
mkdir demoCA
mkdir demoCA/newcerts
touch demoCA/index.txt
echo ffaabb  demoCA/serial
openssl req -key ca4096.key -out ca4096.crt -new -x509 -subj
/C=DE/ST=BW/L=/O=SYSS/OU=/CN=CA -days 3652
openssl req -key 2048.key -out 2048.csr -new -subj
/C=DE/ST=BW/L=/O=SYSS/OU=/CN=www.google.ch -days 365
openssl ca -keyfile ca4096.key -cert ca4096.crt -in 2048.csr -out
2048.crt -days 365

Put the key (2048.key) and the X.509 certificate (2048.crt) to a
ProFTP server and modify the configuration

IfModule mod_tls.c
TLSEngine   on
TLSLog  /var/log/proftpd/tls.log
TLSProtocol SSLv23
TLSRSACertificateFile   /etc/ssl/2048.crt
TLSRSACertificateKeyFile/etc/ssl/2048.key
TLSVerifyClient off
TLSRequired on
/IfModule

Perform a DNS spoofing for www.google.ch and use Cyberduck to access
this system with FTP-SSL (Explicit AUTH TLS).

Solution: Upgrade to Cyberduck 4.4.4

Disclosure Timeline:

April 08, 2014 - Vulnerability discovered
April 08, 2014 - Vulnerability reported to vendor
April 08, 2014 - First Vendor response
April 10, 2014 - Bug was confirmed and fixed by the vendor
April 10, 2014 - Bugfix could be confirmed with Cyberduck 4.4.4 (14478)
April 24, 2014 - Cyberduck 4.4.4 (14505) was released [1]

References:
[1] https://cyberduck.io/changelog/

Credits:
Security vulnerability found by Micha Borrmann of the SySS GmbH.

Disclaimer:
The information provided in this security advisory is provided as is
and without warranty of any kind. Details of this security advisory
may be updated in order to provide as accurate information as
possible. The latest version of this security advisory is available on
the SySS web site.

Copyright:
Creative Commons - Attribution (by) - Version 3.0
URL: http://creativecommons.org/licenses/by/3.0/deed.en

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

The device stopped operating while being set offline

[R P Herrold]

On Tue, 29 Apr 2014, Pavelka, Tomas wrote:

 Can anyone think of a way how to tell that the device is really offline (i.e. 
 in DEV_STATE_DISCONNECTED or DEV_STATE_OFFLINE) so that it is safe to detach? 
 And do this from user mode?

 My current solution is simply to put a short sleep before the CP detach 
 command but that does not seem to be very safe even though I have not been 
 able to reproduce the failure with it.

the latter sounds 'racy'

I know that ClefOS at 6 has 'ethtool' available (successor and
more general than mii-tools) which can detect if a given
interface is 'live', and that will also be in ClefOS 7 ...

particularly useful might be:
ethtool --test (devname) offline

for testing

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: FEDORA F20 boot HCPGIR453W CP entered; program interrupt loop

[R P Herrold]

On Tue, 15 Apr 2014, Dan Horák wrote:

 Because when I reinstalled the guest with /boot on a regular partition
 it survived a kernel update (includes rerun of zipl). Rick Troth
 reported the same problem when he used a kickstart
 (http://s390.koji.fedoraproject.org/test/ks/f20-lvm.ks) that also uses
 all-on-LVM setup.

Testing the hypothesis on an all-on-LVM F 20 setup, I added 
to: yum.conf 
a line: exclude=kernel
and ran updates

[root@clef01 ~]# grep exclude /etc/yum.conf
exclude=kernel

Then after rebooting, the unit restarts without any 
intervention.  

One has to think the initrd is not getting properly fixed up, 
to be able to access the LVM only setup, so it probably makes 
sense to revise: 
http://s390.koji.fedoraproject.org/test/ks/f20-lvm.ks
accordingly, pending a fix.  Dan, is there a bug number on 
this?


2. from the ks.cfg:

...
logvol /boot  --size=500 --name=Boot --vgname=Fedora
logvol swap  --fstype=swap --size=2048 --name=Swap 
--vgname=Fedora
...

Looking at the KS I see also that the swap is going through 
another layer of redirection through LVM, rather than natively 
being placed on the disk.  There are two schools of thought 
here (having swap on LV permits resizing, vs. assumed more 
robust access and performance) but it may make sense to 
migrate it out of the LVM as well

I moved to a 'file based' swap at '/' but on the LVM thus, 
which permits resizing:

cd /
fallocate --length 1GiB RPHswapfile
mkswap /RPHswapfile

and amended the fstab and rebooted, without incident

[root@clef01 ~]# grep swap /etc/fstab
# /dev/mapper/Fedora-Swap swap  swapdefaults0 0
RPHswapfile   swap  swapdefaults0 0

so permitting me to reclaim that swap LV space

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: SLES 11 - Dante server

[R P Herrold]

On Thu, 6 Feb 2014, Mark Post wrote:

 It means the functionality was removed,as stated.  It's gone
 (from SLES) forever unless someone comes up with a very good
 business case to have it returned.

I profess ignorance of the product line and marketing profiles
here.  What socks proxy server for bastion gateways, DOES SLES
offer then.  Perhaps none, I suppose.

cordially,

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Thoughts on multiple certificates for Apache host

[R P Herrold]

On Mon, 2 Dec 2013, Martha McConaghy wrote:

 now has it working, without having to mess with IPs!

 I appreciate the advice, Russ!

* nod *  a pleasure

I _still_ need to write that blog post up about the easy way
to build and test the files.  I blame the turkey I ate

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Thoughts on multiple certificates for Apache host

[R P Herrold]

On Tue, 26 Nov 2013, Martha McConaghy wrote:

 Now, from what little I understand of certs, there can be only 1 per IP
 address.

formerly true, but not so any more for quite some time

see:
  http://www.ietf.org/rfc/rfc3546.txt
for the standard , called SNI -- Server Name Indication
(section 3.1 and following).  The RFC dates from June 2003 but
it took a few years to propigate through the system ;)

 So, if we get cert for the general use web server, it will apply to
 all vhosts on that server.  If we want individual certs for each vhost, we
 would have to supply an IP/NIC for each.  Do I have that correct?  If so,
 any ideas on how to get around that?

As I say, SNI gets around this

http://www.digicert.com/ssl-support/apache-secure-multiple-sites-sni.htm

in browsers that know how to use it.  Any recent browser will;
older browsers should be retired anyway as they almost
certainly have unpatched security issues

http://www.digicert.com/ssl-support/apache-multiple-ssl-certificates-using-sni.htm

[ No particular reason to prefer their doco, but a search on
Google put it forth first ]

We have done it with the StartCom SSL certs as well in the
past.  I recall editting the file from mod_ssl in
/etc/httpd/conf.d/ , rather than the vhost specification .conf
file , but this is local workflow related

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Disabling SELinux

[R P Herrold]

On Wed, 2 Oct 2013, Chase, John wrote:


What else must be done to get the RHEL vm to come up with
SELinux showing disabled instead of permissive in
response to a 'getenforce' command?


adding a line to the relevant grub stanza comes to mind.
Something like this

title SE-Linux Test System
root (hd0,0)
kernel /boot/vmlinuz-2.4.20-selinux-2003040709 ro
root=/dev/hda1 nousb enforcing=0
#initrd /boot/initrd-2.4.20-selinux-2003040709.img

AND in /etc/selinux/config

SELINUX=disabled

but include standard disclaimer

a support person telling you to disable SELinux protections
for anything but diagnostic purposes needs to be escalated
past if they try to suggest that for a production unit

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Disabling SELinux

[R P Herrold]

On Wed, 2 Oct 2013, R P Herrold wrote:


kernel /boot/vmlinuz-2.4.20-selinux-2003040709 ro
root=/dev/hda1 nousb enforcing=0


as:
kernel /boot/vmlinuz-2.4.20-selinux-2003040709 ro \
root=/dev/hda1 nousb enforcing=0

(no backslashes are handled by grub, and the root device will
vary, so amend and re-assemble to one line without a CR break

The mailing list software appears to bave re-laid what should
be on one line ...

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Disabling SELinux

[R P Herrold]

On Wed, 2 Oct 2013, Chase, John wrote:


Part of the problem is that SELinux is not writing any
messages anywhere we can see


In a Red Hat derived environment, when enabled SELinux uses
one of two possible file locations when in enforcing, or
permissive modes:
/var/log/messages
-or-
/var/log/audit/audit.log

depending on whether the 'auditd' is running

With the unit in permissive mode, start in two consoles, a:
tail -f ...
on each file and it should have message appear if that is the
issue

but if a person is randomly adding improper versions and
'feeling their way around' debugging an issue, there is no
telling whan they may have damaged.  See:

http://orcorc.blogspot.com/2013/06/phone-call-ive-got-this-sick-machine.html

about only debugging machines from a known state

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Strange problem with vsFTPD

[R P Herrold]

On Fri, 20 Sep 2013, Mark Post wrote:


On 9/20/2013 at 01:04 PM, Chase, John jch...@ussco.com wrote:

No change.  I'm beginning to dislike this SELinux stuff.


a.  dont be a hater ;)

b.  set a test box (you are not working on a production
instance, right) to 'permissive' in
/etc/selinux/config
and reboot [there are better ways to turn if off, but that is
the easiest to show in an email piece of advice]

c.  the log files can end up either in
/var/log/messages
or
/var/log/audit/

d.  http://orcorc.blogspot.com/search/label/SELinux
should be approhable by mere mortals.  If not lemme know what
your question is

e.  when I read your post, I was thinking of port forwarding
first and the port 21 / 20 vs port 21 only config options of
FTP.  What does tcpdump say?  FTP is a very early protocol and
so turned out to be harder than it needed to be -- thus: http

f.  also there are some iptable rules and a module config file
edit, that need to be tweaked for vsftpd.  Again:

http://orcorc.blogspot.com/search/label/ftp

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Attention: PuTTY users - serious security flaw

[R P Herrold]

On Thu, 22 Aug 2013, John McKown wrote:


Workaround
==

There is no known workaround at this time.


This had a update notice a week or two ago and was patched
back in July.  I read the changes then, and by and large, the
author (Simon) was doing a code audit with 'coverity' as well
as from external reports, and found some items needing to be
addressed

http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/vuln-signature-stringlen.html

There are more cleanups than those cited

It is not at all clear that there is a working exploit.  Simon
notes:


 We are unaware of any way in which this can lead to remote
code execution, since it will typically overwrite the entire
heap with zeroes and PuTTY is expected to crash almost
immediately.


That part of the prior email extract pulled is simply wrong.

From the primary post


   Package  / Vulnerable /Unaffected

---
  1  net-misc/putty 0.63 = 0.63

There was a formal CVE, which is perhaps less excitable
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4852

CVE's tend to lag an update in their issuance

-- Russ herrold
614 488 6954

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Red Hat Linux-based Job Scheduler

[R P Herrold]

On Mon, 22 Apr 2013, Larry Ploetz wrote:


earlier:

We're bringing in an application that will have between 11 and 14 servers
running Red Hat linux.  The vendor is recommending a job scheduler.



GNU's parallel has job scheduling capabilities, as long as you can set
up ssh keys/sessions/whatever that don't require entering a password
(e.g., use an ssh agent, predefine and use controlmaster/controlpath).


interesting -- thanks.  It builds trivially under a Red Hat 6
series derived environment.  Documentation at:

http://www.gnu.org/software/parallel/man.html#example__gnu_parallel_as_queue_system_batch_manager
for using it as a (remote and local) job submission system


We used the 'NQS' system, stabilized by the former Sterling
Software (now owned by IBM), which is available in an open
source variant, again in a Red Hat derived environment for
such purposes.  It was well suited to the task of 'fanning
out, and then re-collating similar tasks across several
machine instances.  Again, it builds trivially in a Red Hat 6
series derived environment.  A short form look at using the
system is in the documentation by a third party is at:
http://www.eecis.udel.edu/documentation/nqs.html

... I have been meaning to re-write a setup, and a user's
'cheat-sheet' guide, but ...

A copy of the Queue manager sources is up at my FTP site:
ftp://ftp.owlriver.com/pub/mirror/ORC/nqs/
I see an RJE tool for non-TCP environments, documented by
Neale of Sine Nomine:
http://www.sinenomine.net/sites/www.sinenomine.net/files/NJEIPBridge.pdf


NASA Ames Research appears to have forked it into 'Portable
Batch Scheduler', and added a enhanced scheduler, but I cannot
immediately put my hands on a FOSS variant of it

http://static.usenix.org/publications/library/proceedings/als00/2000papers/papers/full_papers/bode/bode_html/
The commands appear to be substantially identical to NQS

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Java in RHEL 6.3 on z/VM

[R P Herrold]

On Fri, 22 Mar 2013, Chase, John wrote:


*+ 1   /usr/lib/jvm/jre-1.5.0-gcj/bin/java


Getting Java to behave is a challenge all right

The answer has changed over time but this:
http://www.trading-shim.org/faq/?java

and I see that this page has been update 58 times since it was
started
http://wiki.centos.org/HowTos/JavaOnCentOS

I am thinking that the
/etc/profile
method is your best bet if it is re-sourcing the log-in
environment or something wierd in the application's
'installer'

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: oracle java

[R P Herrold]

On Wed, 20 Mar 2013, David Boyes wrote:


There oughtta be an international Java Proliferation Treaty.



Or a plain REXX port (not Object REXX) that used the JVM
standard pseudomachine.


The problem with any port effort is that the certification
test kit to which one needs to conform to be able to call the
result a Java', is /was non FOSS

http://openjdk.java.net/groups/conformance/docs/JCK6bUsersGuide/html/p4.htm
which indicates even as to the specification:
This document is licensed under a Creative
Commons Attribution-Noncommercial-No Derivative Works 3.0
Unported License

and the IP ownership rights holder was not afraid to use its
tools in litigation
http://www.groklaw.net/pdf2/OraclevGoogle-ApacheSubpoena.pdf
as to third-parties -0- here the Apache Software Foundation

No big deal for companies with legal staffs to thread the
needle, but a non-commercial effort to do such is really a
non-starter

I worked on the issue on the LSB side (a community based
approach):

http://lists.linux-foundation.org/pipermail/lsb-discuss/2008-August/005410.html
and the last word on this is probably:

http://lists.linux-foundation.org/pipermail/lsb-discuss/2010-October/006558.html

A current trailhead seems to be:
http://openjdk.java.net/legal/
for people wishing to bang their head against a wall

-- Russ herrold
614 488 6954

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Excel replacement for linux on z

[R P Herrold]

On Wed, 13 Mar 2013, Herczeg, Zoltan wrote:


   Our operators run many excel vb macros for production on
a windows pc. I wanted to move this workload to a virtual
linux machine on our ifl. Does anyone have any suggestions
for an excel replacement that will run on a linux virtual
machine under z/vm?


Tt sort of depends if a GUI or TUI is needed, and if the
macros are 'common' or complex

A TUI spreadsheet is:
sc
which is tiny -- 640k big.  No longer in active development

gnumeric is a GUI one, and much fatter.  The basic package is
26M, but drags in a whole lot of dependencies
http://projects.gnome.org/gnumeric/

The OpenOffice / LibreOffice suite also exists (and are REALLY
fat), but carries a Java dependency, so depending on the Linux
variant you are using, availability may vary based on that
constraint

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Excel replacement for linux on z

[R P Herrold]

On Wed, 13 Mar 2013, Ejnar Z Rath wrote:


Unless something has changed lately the use of Java is an
option not a dependency for OOo/LO


As I noted, the answer varies by Linux distribution in play
... the problem is more an artifact of solving the build
requirements than of function after it is built

but it is still a pig ;)

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Putty security

[R P Herrold]

On Wed, 6 Mar 2013, Melancon, Ruddy wrote:

I have a security officer that has raised the issue 
regarding free [Putty] software.


Has anyone encounterd security issues with Putty beyond the 
Release 0.60?  I am looking for documented problems.


Putty is a 0.62 in Red Hat's 'rawhide'

It has no recent CVE's noted in the changelog at all

Other than unfamiliarity with not having a commercial vendor 
come to mind, what is the 'issue'?


While I am not, nor have I ever worked for Red Hat, but they 
_do_ and _are_ in the business of selling support contracts. 
They are, or their proxy is, on various GSA and related 
governmental schedules.  They _do_ 'do Windows' too [1]


-- Russ herrold

[1] http://www.cygwin.com/

[herrold@centos-6 ~]$ rpm -qp --changelog \

/mnt/nfs/var/ftp/pub/mirror2/redhat/rawhide/SRPMS/p/putty-0.62-4.fc19.src.rpm   
\
| grep CVE
- Previous release pre-emptively fixed CVE-2006-7162/BZ#231726
[herrold@centos-6 ~]$ rpm -qp --changelog \

/mnt/nfs/var/ftp/pub/mirror2/redhat/rawhide/SRPMS/p/putty-0.62-4.fc19.src.rpm   
\
| head
* Thu Feb 14 2013 Fedora Release Engineering 
rel-...@lists.fedoraproject.org - 0.62-4
- Rebuilt for 
https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild


* Wed Sep 26 2012 Jaroslav Škarvada jskar...@redhat.com - 
0.62-3

- Added missing ImageMagick BuildRequires

* Wed Sep 19 2012 Jaroslav Škarvada jskar...@redhat.com - 
0.62-2

- Generated icon from sources

* Tue Aug 07 2012 Jaroslav Škarvada jskar...@redhat.com - 
0.62-1

[herrold@centos-6 ~]$

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Virus software?

[R P Herrold]

On Wed, 16 Jan 2013, Mark Post wrote:


Yes and no.  Most people I've ever talked to about this seem
to agree that such a tool is needed/desireable only when a
LInux system is acting as some type of a file server for
Windows clients.


heh -- yeah -- PCI / CISP assessors are really literal
minded 'people' ;)

Some require it regardless, without a care for the sense of a
matter

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Really IBM/Tivoli?

[R P Herrold]

On Thu, 6 Dec 2012, Rick Troth wrote:


I would like to publicly ask RedHat to work harder at interoperability.
Some older scripts seem to work, but I/we cannot invoke them the old
way.  Breakage.

The advent of 'systemd' and other fixing-the-wrong-problem
solutions have made it more difficult to have a
common-to-Unix startup. ...


Wearing my LSB hat, my response to this has to be:

Have you filed bugs at Red Hat's tracker, for each
non-conformance you have found ?

If not, please do so and feel free to add my email address in
the 'cc' field, as I track these.  Indeed a 'red-hatter' has
started hanging out in the #LSB IRC channel on freenode, and
so an 'easyfix' may happen

I think you overstate the matter as to systemd.  With the
advent of systemd, there is an express mandate that systemd is
to honor LSB conformant headers in the top of the initscipts.
This makes it easy to avoid pain with systemd (there will be
plenty anyway, but the move of the Linux kernel to udev has
forced Unix's hand)

The general change in computing to 'appearing' and
'disappearing' storage devices (think, USB datasticks) and
network devices (think, moving around between wireless
networks) have pretty well exposed the need for an update to
the older 'init' model

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: SLES11 SP2 install procedures for zseries

[R P Herrold]

On Thu, 9 Aug 2012, Mark Post wrote:


I was about to say correct but I couldn't let it go at
that.  It turns out that you can do it via wget or curl.
Anyone who wants to spend the (inordinately large amount
considering the real level of difficulty) time to figure it
out on their own will probably succeed, but since Ann's case
is a little unusual, I'm going to send her an email off-list
detailing how to do it.


not really rocket science, is it? -- curl and wget can pass
along credentials; or alternatively, if a transient hash is
being used as a substitute as a filepath credential, navigate
through via a web browser, until one can 'copy' the 'payday'
URL from a GUI web browser, to the TUI client

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Kernel ring buffer date stams missing

[R P Herrold]

On Fri, 20 Apr 2012, Aria Bamdad wrote:


by default on s390x.  I also found some stuff online hinting that it is off
on Red Hat also.


Not just a hint -- the Red Hat kernel configuration appears
not to enable it -- but it may be trivially turned on:

# echo 1   /sys/module/printk/parameters/printk_time

(note the slightly different parameter name than in the
article cited))

causes the addition of the time marks:

SCSI device sda: 1465149168 512-byte hdwr sectors (750156 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
    command run as root, and network restarted to get a
dmesg entry
[3243961.352381] ADDRCONF(NETDEV_UP): eth0: link is not ready
[3243962.098996] e1000: eth0 NIC Link is Up 100 Mbps Full
Duplex, Flow Control: RX/TX
[3243962.099073] ADDRCONF(NETDEV_CHANGE): eth0: link becomes
ready
[3243965.528690] ADDRCONF(NETDEV_UP): eth1: link is not ready
[3243967.715865] e1000: eth1 NIC Link is Up 1000 Mbps Full
Duplex, Flow Control: RX/TX

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

ejabberd or Erlang binaries for s390?

[R P Herrold]

On Tue, 17 Apr 2012, Eric Chevalier wrote:


Does anyone know if pre-compiled versions of ejabberd or Erlang for s390
exist anywhere?


Red Hat's Fedora seems to have solved such on s390x

/mnt/nfs/var/ftp/pub/mirror/s390/fedora/F-14/updates/s390x/SRPMS/ejabberd-2.1.6-2.fc14.src.rpm

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: cio_ignore

[R P Herrold]

On Fri, 30 Mar 2012, Mark Post wrote:


On 3/30/2012 at 11:31 AM, Lee Stewart lstewart.dsgr...@attglobal.net wrote:

I've been trying to think of any reason to ever have cio_ignore in a VM
guest.   I can see real use for it in an LPAR where you may have
thousands of devices that have nothing to do with the Linux instance.
But in a virtual machine I only give it the devices I want it to have in
the first place.


I'm guessing this is a Red Hat customer, correct?


I see mention of it on slide 24 in Brad Hinson's (of Red Hat)
presentation at:
http://www.vm.ibm.com/education/lvc/lvc1215c.pdf
which is part of a larger presentation on Red Hat's approach
of a single unified code base for both virtualized and 'real'
hardware

(I too am not, nor have ever been an Red Hat employee, but my
friend Google found the item for me)

It would seem in a VM that one might want to disable
devices that would otherwise be detected, for security
reasons, and perhaps performance reasons

-- Russ herrold
614 488 6954

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: SAS

[R P Herrold]

On Thu, 29 Mar 2012, David Boyes wrote:


I wish. Many people have lobbied for it, and so far, no dice.


It seems a natural for SAS ans an ISV, to conform it ot the
minimal strictres of the LSB and so ship one binary on all
architectures

It's been a long, long time since I touched (and tech
supported) SAS or the old SPSS on the mainframe, back with Mr
Ford was the president

Neale, would 'R' work for the customer's needs? Several high
power, high frequency investment banks, and most of Big Pharma
have moved to it in whole or part, and love it

It is a straightforward rebuild on RPM based distributions,
and natively in Debian ... I have long since all relevant
modules packaged in RPM, and Dirk Eddelbuettel covers Debian

- Russ herold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

RPM install by date

[R P Herrold]

On Wed, 4 Jan 2012, Mark Pace wrote:


Is there a way to get a list of packages installed by date?
rpm -qa --queryformat :date

Did not do it.


check out the --last suboption, and your friend, 'tac' if you need it reversed

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Duplicate rpm packages s390 - s390x, can one of them be removed?

[R P Herrold]

On Tue, 20 Sep 2011, Richard Troth wrote:


In the case of libraries, it is normal to have both architectures
installed.  Desirable even.  So ... again ... check what is supplied,
and if they are libs, don't sweat it.


Not sure about 'Desirable' actually.  If a file is not needed,
or useful, it has no business clogging up a filesystem and
dynamic linker search path (slowing the machine carrying
around the non-used parasite)

I have removed the non s390x 'multi-lib' packages, under the
guidance of rpm, which 'knows' from its use of ldd, and other
tools, which are 'safe' to remove, with no ill effects

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

BASH scripts are a trade secret?

[R P Herrold]

On Wed, 17 Aug 2011, McKown, John wrote:


Most weird. At least to me. Well, I guess it is possible to
use a BASH script where most would use C code. But a trade
secret that you distribute in source form?

http://www.clustermonkey.net//content/view/308/1/


It is a footnote, buried down in the story, but Rocky McGaugh,
a friend, and co-founder of CentOS, was hounded and felt a
need to escape Atipa's harrassment through suicide.

He, Greg Krutzer (cAos / Warewulf clusters) and I 'pitched' a
CentOS like product to an IBM VP at the Supercomputing held in
Phoenix, back in what, perhaps November 2003?  He was
straightforward and I enjoyed working with him.  I miss him


Contracts need to be enforceable, and it may well be that a
'trade secret' exists in content provided by Atipa ... but it
may be also that they have simply ignored prior copyrights and
slapped trade secret language on everything in sight ... I see
that a lot in FOSS content being 'taken private' in such an
improper re-labelling of the content of others.

The web-archive page lists the following organiztions as
customers of Atipa as of Feb 2004.  If you are affiliated with
any of the following, one way to express dissatisfaction with
such tactics of litigating in the courtroom, rather than
through technical merit, might be to help your local
institution find a replacement for Atipa kit

 Accurate Environmental Forecasting
- Ames Labs
- Argonne National Laboratory
- Arizona State University
- Army Corps of Engineers
- ATT
- California State University
- Carnegie Institution of Washington
- Case Western Reserve
- Cessna
- Clemson University
- Colorado School of Mines
- Colorado State University
- Colsa Corporation
- Conexant Systems, Inc.
- Conoco
- Dartmouth University
- Drake University
- Duke University
- Embry-Riddle Aeronautical University
- Exxon
- Federal Aviation Administration
- Federal Bureau of Investigation
- Fermi National Accelerator Lab
- George Washington University
- Harvard University
- Indian Institute of Science (India)
- Iowa State University
- Jet Propulsion Lab
- Kansas State University
- Los Alamos National Laboratory
- Louisiana State University
- Lucent Technologies
- Massachusetts Institute of Technology
- Michigan State University
- Mission Research Corporation
- Mississippi State University
- Montana State University
- Motorola
- NASA
- National Center for Atmospheric Research
- National Centre for Biological Sciences (India)
- National Ocean and Atmospheric Administration
- Naval Research Labs
- Naval Surface Warfare Center
- Oakridge National Labs
- Oklahoma State University
- Old Dominion University
- NREL
- Pennsylvania State University
- Pittsburg State University
- Princeton University
- Raytheon
- Sandia National Labs
- Sprint
- Sprint PCS
- Stanford University
- Syracuse University
- Texas AM
- Texas Tech University
- The Johns Hopkins University
- UCLA
- University of Akron - Ohio
- University of British Columbia
- University of California - Davis
- University of California - Riverside
- University of California - Santa Barbara
- University of Chicago
- University of Colorado
- University of Connecticut
- University of Delaware
- University of Illinois
- University of Kansas
- University of Michigan
- University of Mississipi
- University of Missouri
- University of Nebraska
- University of New Orleans
- University of North Carolina
- University of North Dakota
- University of Oklahoma
- University of Oregon
- University of Pennsylvania
- University of South Florida
- University of Southern Mississippi
- University of Tennessee
- University of Texas
- University of Utah
- University of Virginia
- University of Washington
- University of Wisconsin
- University of Wisconsin - Milwaukee
- US Air Force
- US Army
- US Army Corps of Engineers
- UT Southwestern Medical Center
- Wayne State University
- Wichita State University
- Yale University

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: ASCII to EBCDIC conversion

[R P Herrold]

On Tue, 14 Jun 2011, Richard Troth wrote:


The FTP server on the EBCDIC system should handle translation of text
files.

Let the EBCDIC side do the translation.


heh -- easily said  ;)

I had a situation where I was receiver and sender as a
counterparty on credit card clearance data, in EBCDIC format.

The counterparty was so dysfunctional in its internal
processes, that it made sense to solve the issues of
conversion locally, rather than fight the inertia on the other
end

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Shared root and shutdown

[R P Herrold]

On Tue, 10 Aug 2010, Richard Troth wrote:


Russ ---

YOU ... are ... SPOOKY
How can you remember a date so accurately.


'sent mail' archives and grep, on the confirmation on that
lunch -- at Damon's of the Olentangy River Road, with the
midrange global Linux architect for another firm here in town
;)


It was Steve who suggested making the root RO and shared.  I had only
been pushing for shared /usr and things.  Sun used to share /usr
heavily, as I have said many times, so there is precedent in the
non-VM and non-z world, so it should not be a weird idea to other
Linux developers, distributors, and customers.  But Steve took it up a
notch and I am hooked.


It is a compelling idea, at the expense of some re-jiggering
of the initrd, and mounts.  The 'deduplication' gain is
compelling, and I have repeated the idea on VM work we have
done since


RPM is (still) the biggest part of the problem.  Not RPM per se, but
the practices surrounding RPM based packaging.  (Same goes for
Debian.)


For those late to the party, I served as the Editor of the RPM
website for many years, and talk daily with the long-time RPM
maintainer, Jeff Johnson, who now does consulting work in
packaging space (as I do)  All the issues of the RO compoennt
are long since known and solved, and really the issue is that
a distribution packaging strategy designed to meet the needs
of 'onsies and twosies' installs, is not well suited for
hundreds or thousands of replications.

A entity with enough mass to be running more than a couple
hundreds instances needs to have packaging skills (in house,
or contracted as needed), and basically ends up spinning a
'local rework' of some vendors base [commercially: RH's or
SuSE's; community: CentOS, Debian testing, are the best
suited], re-jiggered to meet local needs.  It is the only
sensible to out-compete one's peers in this space

-- Russ herrold
herr...@owlriver.com
herr...@centos.org
herr...@pmman.com

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Shared root and shutdown

[R P Herrold]

On Tue, 10 Aug 2010, Edmund R. MacKenty wrote:


I'm still wondering what RPM issues with read-only
filesystems have been solved.  Russ, are there any docs you
can point us to on that?  I ended up doing essentially what
you suggested: letting an admin maintain software on one
system using RPM, and having my tool distributing those
changes to the many Linux instances it has created, dealing
with R/O filesystems in its own way.


Some of the the live CD [really, live ISO images] creation
tools leave the RPMDB present and intact, even though on RO
media, particularly when that live CD (DVD).  The process is
merely laborious, and once solved readily scriptable, as you
and others have noted as in the nicely comprehensive RedBooks
mentioned yesterday

Install into a DD'd base image, having suitable -bind
mounted visibility into /proc/ dev, and /sys
under a 2.6 kernel
Fix up mount points that need to be RW, to be such
Toss a link out of the RO FS for /etc/mtab  ;)
Adjust the (custom) initrd scripts to do:
- rsyncs, cp -a, or other relocations of
content that needs to be RW, during the
phase one boot
(tmpfs is wonderful here)
- does the mounts of RW partitions
- perhaps do path munges so that the
/bin and /sbin/ within the RO come at
the end of the search paths under
different path names, so that transient
or machine image specific rpm updates
in the RW space take precedence (ditto
libraries -- this is where managing
the variant distribution part gets
tricky

and of course, Rinse, Test, and Repeat

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Shared root and shutdown

[R P Herrold]

On Mon, 9 Aug 2010, Michael MacIsaac wrote:


The first time we wrote about it, based on the work of Rick Troth, Steve
Womer, et al, (http://www.redbooks.ibm.com/abstracts/redp4322.html) /etc/
was bind-mounted, and glancing through the paper quickly, I don't see
anything specific to umount it during shutdown.  Perhaps Rick could
elaborate.


Spooky to see how it turned out -- I feel like an enabler; I
went to lunch with Steve and Rick 23 March 2006 to suggest
approaches within the RPM package management system to enable
such an approach ;)

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Graphviz - Graph Visualization Software on SuSE SLES10 zSeries ?

[R P Herrold]

On Tue, 15 Jun 2010, Marco Bosisio wrote:


 I  have a request  to verify   if   Graphviz   http://www.graphviz.org/
runs  on   zLinux


[herr...@centos-5 ~]$ ssh ibm.owlriver.net
Last login: Wed Jun  9 15:18:04 2010 from (elided)
[herr...@ibm ~]$ uname -a
Linux ibm.owlriver.net 2.6.9-42.EL #1 SMP Wed Jul 12 23:21:43 EDT 2006 s390x 
s390x s390x GNU/Linux
[herr...@ibm ~]$ rpm -q graphviz
graphviz-2.8-1.sl
[herr...@ibm ~]$

works fine on a RHEL variant, and so it should build and run
on SLES as well

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

zPDT usage

[R P Herrold]

On Mon, 14 Jun 2010, Frank M. Ramaekers wrote:


Anyone using or plan on using IBM System z Personal Development Tool
(or ITC zPDT)?



http://www.redbooks.ibm.com/abstracts/sg247721.html?Open


hmmm; new text


Starting with the E41.18 release of zPDT (spring 2010) the
1090 installation process checks for specific Red Hat and
openSUSE indicators and is not installable if one of these
distributions is not detected.4

at page 24

and a footnote indicating some other distributions may pass
the tests (so a test seemingly looking fo text strings, rather
than any needed library feature; shame shame) --- Is it _so_
hard to look for the LSB features, and so let ALL LSB
compliant distributions run?

As I recall, the pricing was hard to justify for the Community
distributions, such as CentOS, where I toil

-- Russ herrold

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Download Centos

[R P Herrold]

On Wed, 3 Mar 2010, David Boyes wrote:


Suggestion: download the RHEL 4 for s390x starter image from your fave RH
mirror, use the kernel and initrd to get a working system up, install yum,
and point it at the centos repository. Yum update, yum upgrade and a lot of
network traffic later, you have a working Centos.


perhaps, but it hardly seems fair to the engineering work that
Red Hat has done to bootstrap in that way.

I've asked here for gratis remote access to relevant hardware
to work out install testing and build issues, particularly as
to install issues before, to produce and stabilize the Centos
5 series, and updates for 4 and 5, but no offers have
resulted.  Feel free to contact me offlist if you are shy
about this

I'll do the CentOS level build, verify and integration work,
but it is pretty empty without the ability to see and resolve
the installer issues

-- Russ herrold
herr...@centos.org
herr...@owlriver.com
614 488 6945

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390