Re: nmcli question

[Ken Teh]

On 04/10/2017 10:59 AM, Tom H wrote:



The lead NM developer's replied to you on fedora-devel@ or
fedora-user@ in the past that he and his fellow NM developers have
worked hard to add to NM configuration options for complex server
setups as well as a cli tool for managing settings. Sadly, NM seems to
be a project that can do nothing right in the eyes of its users even
though it's left the flakiness of its early years behind.




I'm not sure why I'm jumping into the fray but this paragraph struck me as to 
exactly why network manager is anathema to so many of us.  Even if it is not as 
flaky as it used to be.


I'm living with it but I can't you the number of times  nmcli and firewall-cmd 
have made my blood pressure go up.   The latter is even worse with its option 
style subcommands and is near impossible to remember choices.  Is it  list-all, 
zone-get-info,  zone-list-all?   Wtf?

Re: RAID 6 array and failing harddrives

[David Sommerseth]

On 10/04/17 09:15, Tom H wrote:
> zfs'll never be in-tree for licensing reasons.

Well, "never" might be a too strong word.  Stranger things have
happened, like Microsoft embracing Linux and open source; even starting
to open up some of their closed projects as open source ;-)

But I'll give you that Oracle is probably a very different beast on the
legal side and doesn't have a too good "open source karma".


-- 
kind regards,

David Sommerseth

Re: RAID 6 array and failing harddrives

[David Sommerseth]

On 10/04/17 10:43, Tom H wrote:
> On Thu, Apr 6, 2017 at 5:01 PM, David Sommerseth
>  wrote:
> 
> 
>> I would never run btrfs on *any* production server, regardless of
>> currently available kernel versions. Because it is not deemed ready
>> for production yet. For testing I would be willing to experiment with
>> it, as there I can tolerate data loss. But never ever in production.
> 
> It's being used in production at Facebook and in Oracle Linux and SUSE Linux.
> 
> I don't know how SUSE does it but Oracle Oracle has kernel and
> kernel-uek packages. The kernel package is the same as SL's and the
> kernel-uek package provides a more recent kernel that goes
> hand-in-hand with the more recent btrfs tools.

Last time I checked, SUSE Linux typically had disabled all of the really
useful btrfs features which makes it more interesting than XFS/ext4.
But I'll admit my reference point is a few years old by now (approx as
old as RHEL7 is).

What Facebook does, I have no idea how they use it.  It might even be
used in areas where data loss is acceptable due to data being replicated
elsewhere too.  Or again, that some features are disabled again.
Sailfish OS (by Jolla) have used btrfs by default on their mobile OS,
that worked fine there too.  But I doubt that also used the most
interesting features.

In regards to Oracle, IIRC, they also employ many of the upstream btrfs
developers.  But I wonder how well they support it for customers
installing it in production, and which features are fully supported.

That is one of the true things which makes it hard to compare btrfs too
even between distros.  Each distro have their own opinion of which
features could/should be enabled.


-- 
kind regards,

David Sommerseth

Re: nmcli question

[Tom H]

On Sat, Apr 8, 2017 at 10:59 PM, Nico Kadel-Garcia  wrote:
> On Sat, Apr 8, 2017 at 5:36 PM, ~Stack~  wrote:


>> I will spare the details, but suffice to say I am in a position where
>> after many years knowing the 'network' commands I've been tasked to
>> learn nmcli much better than I do now. This is all on SL7.
>
> Oh, you poor beggar. I feel your pain. Notes that I published years
> ago for CentOS 5 and CentOS 6 pair bonding just went obsolete, in
> completely undocumented and unintelligible ways, with upstream RHEL 7
> and Fedora's fascination with "NetworkManager" instead of anything
> stable or scriptable. I feel your pain a *lot*.

You follow federo-devel@, so you must've seen one/two/three years a
post by one of the RH developers who works on the core packages of
Fedora saying that they didn't want to keep on maintaining the scripts
in "/etc/sysconfig/network-scripts/". Between that lack of interest
and the desire to have the network be handled dynamically by a daemon,
it wouldn't be surprising if a future RHEL8 or RHEL9 drops the
"/etc/sysconfig/network-scripts/" infrastructure.

It's unfortunate that distributions have always had an NIH attitude to
network management (other than NM and systemd-networkd). From the ones
that I use:

- Debian and Ubuntu have "/etc/init.d/networking", "/etc/network/*",
and "/sbin/if{up,down}" (the latter being compiled executables)

- Fedora and RHEL have "/etc/rc.d/init.d/network" and
/etc/sysconfig/network-scripts/*"

- Funtoo has "/etc/init.d/netif.tmpl", "/etc/netif.d/*", and
"/etc/conf.d/netif."

- Gentoo has "/etc/init.d/net.lo", "/lib/netifrc", and "/etc/conf.d/net"

- Slackware has "/etc/rc.inet{1,2}" IIRC (I had to manage some
Slackware servers for a few months two years ago so I might be
misremembering the script names)

:(


>> I've been reading documents, building and tearing down networks for
>> hours, and trying to put into practice what I'm learning (still a long
>> way to go; haven't touched the infiniband parts yet). Something keeps
>> coming up in documentation that bothers me.
>>
>> Here is an example of one of *many* documents:
>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Network_Configuration_Using_sysconfig_Files.html
>>
>> They mention taking down a network with:
>> $ nmcli dev disconnect interface-name
>>
>> but bringing it up with:
>> $ nmcli con up interface-name
>>
>> That is so infuriating to me. Why use different sub-commands? Especially
>> when there exist subcommands in the same context? Why not do this?
>> $ nmcli dev disconnect interface-name
>> $ nmcli dev connect interface-name
>
> Because they're trying to weld NetworkManagers's graphical interface,
> on top of poorly integrated command line interface, on top of the
> actual underlying bash scripts that do the real work. It's Fugly Out
> There(tm).

"nmcli conn ..." is for managing a network connection (ip addresses,
routes, nameservers, bonding/bridging/tagging) so you can bring down
the connection with "nmcli conn down ...".

The difference between "nmcli conn down ..." and "nmcli dev disconn
..." is that the latter prevents the connection from being
auto-activated.


> In case it's unclear I am *not* happy with NetworkManager for servers
> or stable environments. Laptops that have to wander from environment
> to environment need multiple VPN's, yeah, OK, I can see having a more
> complex tool. But for a VM? Or a server?

The lead NM developer's replied to you on fedora-devel@ or
fedora-user@ in the past that he and his fellow NM developers have
worked hard to add to NM configuration options for complex server
setups as well as a cli tool for managing settings. Sadly, NM seems to
be a project that can do nothing right in the eyes of its users even
though it's left the flakiness of its early years behind.


> I'd like to introduce you to wone of my favorite settins for
> /etc/sysconfig/network-scripts/ifcfg-* files, or even for
> /etc/sysconfig/network, or if you feel really paranoid, /etc/profile.
>
> NM_CONTROLLED=no
>
> Turn *off* NetworkManager manipulation for anything that doesn't need it.

I prefer to delete ifcfg-* files and use NM keyfiles. For a bridge:

# cd /etc/NetworkManager/system-connections

# cat bridge0-master
[connection]
id=bridge0-master
type=bridge
uuid=84eaf7e7-a020-481b-9709-28892d61701c
[bridge]
interface-name=bridge0
stp=false
[ipv6]
...
[ipv4]
...

# cat bridge0-en0
[802-3-ethernet]
mac-address=28:d2:44:0e:2f:53
[connection]
id=bridge0-en0
master=84eaf7e7-a020-481b-9709-28892d61701c
slave-type=bridge
type=802-3-ethernet
uuid=0617b1c0-becb-4921-905b-a70d2e61e12d

That way there's no confusion between the use of "network.service"
config files and "NetworkManager.service" config files. And there's no
need to learn nmcli commands.


>> Or even this?
>> $ nmcli con down interface-name
>> $ nmcli con up interface-name
>>
>> As far as I can tell, they are both 

Re: [SCIENTIFIC-LINUX-USERS] fermilab-conf_doe-banner-console is not fully uninstalled by yum remove

[Pat Riehecky]

On 04/06/2017 07:09 AM, Dan wrote:

On Sun, 2 Apr 2017, Dan wrote:


Yesterday, I accidentally (as part of a more general yum install
invocation with some wildcards in it) ran:
yum install fermilab-conf_doe-banner-console
This wrote a passage of text to /etc/motd, causing a vaguely
threatening message, purporting to constitute a legally-binding
contract, to appear on screen at boot time.
However, subsequently running
yum remove fermilab-conf_doe-banner-console
does not remove the passage of text from /etc/motd, and does not stop
the message from appearing at boot time.


Well, thanks to Pat's swift production of a new version of
fermilab-conf_doe-banner-console (followed by another cycle of yum
install and yum remove by me), the text has now been deleted from
/etc/motd.

Unfortunately, the threatening-sounding message is still appearing at
boot time.  Digging a little deeper, I think this may be because

yum install fermilab-conf_doe-banner-login-screen

writes the relevant text into
, and a subsequent

yum remove fermilab-conf_doe-banner-login-screen

doesn't remove the text from that file.  Pat, I think you're the
maintainer of that package too, right?  Any chance of a similar fix
there, please?



I'll take a look!

Pat

Re: RAID 6 array and failing harddrives

[Tom H]

On Thu, Apr 6, 2017 at 5:01 PM, David Sommerseth
 wrote:


> I would never run btrfs on *any* production server, regardless of
> currently available kernel versions. Because it is not deemed ready
> for production yet. For testing I would be willing to experiment with
> it, as there I can tolerate data loss. But never ever in production.

It's being used in production at Facebook and in Oracle Linux and SUSE Linux.

I don't know how SUSE does it but Oracle Oracle has kernel and
kernel-uek packages. The kernel package is the same as SL's and the
kernel-uek package provides a more recent kernel that goes
hand-in-hand with the more recent btrfs tools.


>> But the "kmod" release of ZFS seems to work well enough. I do have to
>> disable automatic kernel updates, but that may be wise in some
>> configurations anyway, YMMV.
>
> By all means, if you feel confident you will get the needed help
> sorting out issues you hit on ZFS, go ahead. I would never do that,
> even for ZFS. Once Red Hat enabling ZFS on a kernel where it is native
> in the upstream kernel, not being labelled tech-preview - that day I
> will consider ZFS for production. If btrfs reaches this stage earlier,
> then I will consider btrfs instead.

As I said in a previous email, zfs isn't going to be in-tree (unless,
of course, Oracle changes its license...).

Other than having installed Ubuntu on btrfs twice in a VM and played
around with it, my knowledge of btrfs comes from gentoo-user@. Two
things stand out from those threads. The btrfs developers seem to be
more interested in adding features than in stability (in the words of
committed btrfs users; more interested in features doesn't mean that
stability is ignored) and, except for one or two kernels where there
were regressions, every new iteration seems to bring better stability.


> For me, the safest option _now_ is mdraid + LVM + XFS/ext4. Which
> combined is somewhat closer (but not directly comparable) to the
> features I like in both btrfs and ZFS. In addition, I know and
> understand the toolset needed for mdraid + LVM + XFS/ext4 fairly well,
> so I don't have to spend much extra time figure out the tooling if
> something bad happens. But I'm also not going to spend time learning
> btrfs/zfs tooling until it begins to be ready for production use.

Not quite. Unlike btrfs, zfs is stable but it doesn't fulfill your
in-tree criterion...

Re: Brainfart: Academic paper rewrite tool

[Nico Kadel-Garcia]

On Sun, Apr 9, 2017 at 10:17 PM, Keith Lofstrom  wrote:
> I watched "The Internet's Own Boy" about Aaron Swartz a few
> days ago.  Wonderful motivation: make academic literature
> publically accessable.  Stupid juvenile implementation:
> download a million papers from JSTOR in an MIT wiring
> closet.  Horrible outcome: Federal prosecution, suicide.

He was apparently also stealing the *organization* and layout of the
content, including the descriptions of the papers. *That* is new
analysis material, copyrightable by JSTOR.

> I want to make the information contained in academic
> literature publically accessable ... and versioned, and
> updated, and weblinked, and supported.  The academics
> here might have some ideas.

Use JSTOR. It's a paid service, but it's a non-profit and very
generous with grants and generous about clients who share access. Like
paying a janitor clean the bathrooms, it's a modest fee, for an
*amazingly* useful service. If you can help raise the money to get
their very good services in all pubic libraries Oh, wait!!! It is,
in many hundreds if not thousands of libraries across the land? JSTOR
gives *amazing* discounts for libraries. the infrastructure and time
to organize it is large, and not cheap.

> What if:  We (meaning those more capable than me) construct
> a software environment for disassembing the pdf elements of
> an academic paper, which a moderately literate person can
> use to REWRITE and redraw and reformat the paper as a
> substantially different work with an updated version of
> the same information in it?  I am inspired by some of the
> capabilities in Inkscape for reworking graphics into SVG.
>
> What if we improve that process, for example tying a graph
> in an old paper to data from new research that verifies,
> refines, or refutes it?  Move the slider on the graph from
> an original 1960 paper to a new graph that incorporates
> 2017 data?

I'm skeptical you can do this well enough, with a specialized enough
set of tools to make it worth it. It's a "Computer Aided Design", or
CAD project. And those rarely get enough membership to do well.

Your best bet for free is to print the original content as PDF's, and
apply either ImageMagick (for free) or Adobe PDFCreator (for a good
commercial editing tool).

> I have about a dozen published journal papers out there
> (one with over 200 citations) that I would love to
> "de-copyright" out of the clutches of the IEEE, Elsevier,
> etc.  My newest stuff is publically posted as pre-
> publication drafts before I submit it, but I would love
> simple tools that would ease the process of liberating
> my older work.  I'd be glad to help as an alpha-test
> guinea pig, also use the tool for new writing projects.

See above. What I

> ... and an open, updatable, friendly version of the
> document that 99% of the world will actually use.
> Personally, I would love it if my best papers outlived
> me by centuries, steadily improving and accumulating
> hundreds of coauthors into the far future.

Then I hope they were *really, really good* and worth spending the
time on. It seems unlikely.

> While this would be a very complicated suite of tools to
> write, it's gotta be a lot easier than designing rockets
> and self-driving cars.
>
> Am I nuts?
>
> Keith

You're nuts. There's little to no short term return on the investment,
none of which you've actually done, and to compete with tools which
exist. TeX, and LaTeX, tried to do this and the gui LyX eventually
evolved to help with it. But it relied on TeX formatting, which was
overwhelmingly discarded as Word took over document writing, and PDF
took over stabilization of printable documents. Also, the "we need to
spend all our time picking the unique font for *our* institution's
publications!!!" nuttiness became a compatibility nightmare.

Most of the documents you refer to can be printed out as editable,
consuming PDF, including what is at JSTOR and almost all the modern
on-line published scientific literature today. If you'd like to invest
the work, or gather support, I'd urge working with and improving PDF
editing tools. And if co-authors are going to edit and modify, you're
going to *need* to trace provenance, and come to grips with copyright
law. Those are better places, I think, to spend the effort to make
shared scientific compilation feasible. If I see such a paper, I want
to know which person did the original research and what bozo added the
parts about breeding mammoths inside of female elephants.

In fact, for good scientific provenance, I *don't* want editing after
Footnotes by others, or a side-by-side guide like a Cliff's Notes?
Those have uses. But leave the original language and wording
*alone*!!!

Endearingly optimistic, and if you can get traction on it, cool. But
you don't get much traction on the many thousands of "wouldn't it be
nice" ideas if you don't actually sit down and write the code, or
spend the money to get someone else competent to write 

Re: RAID 6 array and failing harddrives

[Tom H]

On Thu, Apr 6, 2017 at 8:15 AM, David Sommerseth
 wrote:
> On 06/04/17 10:54, Tom H wrote:
>> On Wed, Apr 5, 2017 at 5:50 AM, David Sommerseth
>>  wrote:
>>>
>>> ZFS looks great, so does btrfs - on the paper. But until ZFS is native
>>> in Linux or btrfs stabilizes on the same level as ext4 and XFS, I'm
>>> not going that path for production environments.
>>
>> What do you mean by "native?"
>>
>> The upstream deb and rpm files use dkms (as well as kmod for RHEL and
>> clones) and Ubuntu ships zfs pre-compiled. This is "native" in my
>> book.
>>
>> I've used and am using zfs in production on Linux and it's good and stable.
>
> My meaning of "native" is that it is included in the upstream Linux
> kernel, not a side-loaded product/project/kernel module.

Thanks. I read a later email in which you said that.

zfs'll never be in-tree for licensing reasons.