What's on your list?

[Joe Rosevear]

Howdy,

In a different post I described how I got my printer working.
Basically, I twiddled with Slackware's foomatic-rip filters. For more
information go to:

http://joeslife.org/news

This raises a talking point. I wonder if my printer fix needs to be
included somehow in Slackware? I think, perhaps, it should at least be
listed under the heading of "You Might Want to Change This".

I should keep my own list. Here is a first draft:

You Might Want to Change This
-----------------------------

1. The foomatic-rip fix: Mentioned above. Fixes foomatic rip
printing in Slackware 14.2.

2. The Diffie-Hellman fix. I don't know when this became
necessary, but /usr/bin/ssh doesn't work for me. I need to rename
it (/usr/bin/ssh__mods) and replace it with a script like
this one.

#!/bin/sh

/usr/bin/ssh__mods -oKexAlgorithms=diffie-hellman-group1-sha1 $*

3. The backspace fix. I write scripts which prompt for replies.
Sometimes a backspace is needed when replying, but it won't work
without this fix which I learned here in this Usenet group from Alan
Hicks in 2008:

if [ "$TERM" = "xterm" ]; then
stty erase $(tput kbs)
fi

Put the above code in your .bashrc (along with your exports and
aliases).

What's on your list?

-Joe

[Sylvain Robitaille]

Post by Joe Rosevear
...
2. The Diffie-Hellman fix. I don't know when this became
necessary, but /usr/bin/ssh doesn't work for me. I need to rename
it (/usr/bin/ssh__mods) and replace it with a script like
this one.
#!/bin/sh
/usr/bin/ssh__mods -oKexAlgorithms=diffie-hellman-group1-sha1 $*

That's an ugly hack. I have a policy (both personally and at work for
systems I manage there) whereby I make the smallest change necessary at
the OS level to accomplish what I'm after. Anything that can be
accomplished by configuration, of course is done by configuration. See
ssh_config for details of how you (arguably) should have done the above.
We have some old systems at work whose light-out management interfaces
don't work with newer ssh key exchange algorithms. I have the following
in my ~/.ssh/config file to accomodate those:

Host *.console.private
KexAlgorithms +diffie-hellman-group1-sha1
Ciphers +3des-cbc
HostKeyAlgorithms +ssh-dss

The same in /etc/ssh/ssh_config would provide the same result on a
system-wide basis.

Post by Joe Rosevear
What's on your list?

Lots of little changes ... here are some selected extracts:

- change default run level to 4
- /usr is mounted read-only
- enable syn cookies
- have sshd lookup hostnames for incoming connections
- enable ntpd
- "su" is available only to group 0
- setuid-root files are runable only by group "users" (with few
exceptions where that restriction is non-trivial)
- a couple of vim settings

[Joe Rosevear]

Post by Sylvain Robitaille

Post by Joe Rosevear
...
2. The Diffie-Hellman fix. I don't know when this became
necessary, but /usr/bin/ssh doesn't work for me. I need to rename
it (/usr/bin/ssh__mods) and replace it with a script like
this one.
#!/bin/sh
/usr/bin/ssh__mods -oKexAlgorithms=diffie-hellman-group1-sha1 $*

That's an ugly hack.

Yes, I suppose it is. I actually felt a twinge of guilt when I did it.
It poses a small danger that later I'll upgrade and lose track of what
I did. Otherwise, except for being non-standard, its pretty safe I
think. It is just a wrapper, and I feel good in my belief that it
won't interfere with how it functions. Of course, I might be wrong.

Anyway, I didn't have time to reasearch the correct way to do it.
That's why I appreciate your comments. Perhaps now I know how.

Post by Sylvain Robitaille
I have a policy (both personally and at work for systems I manage
there) whereby I make the smallest change necessary at the OS level
to accomplish what I'm after.

Yes, it is good to live (and work) by guiding rules. I don't often
think about mine, however. Perhaps I would profit from writing them
out or at least putting them into words as you have done above.

Yet even if I did this, my rules would likely be different from yours.
I'm a paraeducator at an elementary school. The computer work that I
do is in addition to my normal tasks and is often done for no pay. I
am currently the keeper of about two dozen Slackware-running computers
for mostly students. I am the only person who does any admin work on
those computers.

Your situation, I'll bet, is rather different from mine.

Post by Sylvain Robitaille
Anything that can be accomplished by configuration, of course is done
by configuration. See ssh_config for details of how you (arguably)
should have done the above. We have some old systems at work whose
light-out management interfaces don't work with newer ssh key
exchange algorithms. I have the following in my ~/.ssh/config file
Host *.console.private
KexAlgorithms +diffie-hellman-group1-sha1
Ciphers +3des-cbc
HostKeyAlgorithms +ssh-dss
The same in /etc/ssh/ssh_config would provide the same result on a
system-wide basis.

Right. It looks like I would, in fact, want to use
/etc/ssh/ssh_config, and I only need the KexAlgorithms line. I'm
guessing my first line should be "Host *", as I want this to apply to
all hosts. Is that how it works?

Post by Sylvain Robitaille

Post by Joe Rosevear
What's on your list?

- change default run level to 4

I played with run level 4, but I don't use it. Instead, I set up
inittab to invoke /usr/local/bin/autologin.sh in this way:

a1:1235:wait:/sbin/agetty -l /usr/local/bin/autologin.sh -n 38400 tty1 linux

Honestly, I'm doing this in a cookbook sort of way, so I can't tell you
much about what the above does, except that it works. This gives a
handy auto-login. Through use of startx in the .profile this gives me
a one-touch startup that goes all the way to a ready desktop. Just
press the power button.

(Right. I'm different. I don't leave them on all the time. They shut
down automatically at 6:00 PM.)

Post by Sylvain Robitaille
- /usr is mounted read-only
- enable syn cookies

I had to look up "syn cookies". Interesting.

Post by Sylvain Robitaille
- have sshd lookup hostnames for incoming connections
- enable ntpd
- "su" is available only to group 0
- setuid-root files are runable only by group "users" (with few
exceptions where that restriction is non-trivial)
- a couple of vim settings

That's quite a list. I'll bet your admin work keeps you busy.

-Joe

[Chris Vine]

On Fri, 13 Jul 2018 00:29:27 +0000 (UTC)
Joe Rosevear <***@localhost.invalid> wrote:
[snip]

Post by Joe Rosevear
Right. It looks like I would, in fact, want to use
/etc/ssh/ssh_config, and I only need the KexAlgorithms line. I'm
guessing my first line should be "Host *", as I want this to apply to
all hosts. Is that how it works?

You could have that as your first line in ssh_config but (on
slackware-current at least) it is the default if you do not provide any
'Host' or 'Match' line. In other words, in slackware-current the
options given (if any) before any 'Host' or 'Match' line are assumed to
be global, so all the options are global if no 'Host' or 'Match' line
is provided.

You must have a 'Host' or 'Match' line if you want different options to
apply to different sites/hosts. The scope of any 'Host' or 'Match'
line begins with that line and ends at the next 'Host' or 'Match' line
(if any). Matching is in the lexical order provided in the ssh_config
file, so you _must_ have a 'Hosts *' line with final section following
it if you want to specify particular options for specific hosts and
general options for all others. That doesn't seem to be your situation.

The ssh_config file in /etc/ssh gives you the (commented out) default
settings used by ssh.

[Sylvain Robitaille]

On 2018-07-13, Joe Rosevear wrote:

(ssh wrapper script to set configurable options)

Post by Joe Rosevear

Post by Sylvain Robitaille
That's an ugly hack.

Yes, I suppose it is. I actually felt a twinge of guilt when I did
it. It poses a small danger that later I'll upgrade and lose track of
what I did.

Honestly, that's its biggest drawback.

Post by Joe Rosevear
Otherwise, except for being non-standard, its pretty safe I think. It
is just a wrapper, and I feel good in my belief that it won't
interfere with how it functions. Of course, I might be wrong.

I don't think you are.

Post by Joe Rosevear

Post by Sylvain Robitaille
I have a policy (both personally and at work for systems I manage
there) whereby I make the smallest change necessary at the OS level
to accomplish what I'm after.

Yes, it is good to live (and work) by guiding rules. I don't often
think about mine, however. Perhaps I would profit from writing them
out or at least putting them into words as you have done above.

I think it's key to be able to describe such a notion in a simple
sentence. Much easier that way to remember it, and to follow it.
But then you need to apply the discipline to stick to it. If you
have to make exceptions, the policy needs to be adjusted instead,
because it doesn't yet fit your environment.

Post by Joe Rosevear
Yet even if I did this, my rules would likely be different from yours.

Of course.

Post by Joe Rosevear
I'm a paraeducator at an elementary school. The computer work that I
do is in addition to my normal tasks and is often done for no pay.

Sure, but you do still want to do work you can be proud of and feel it
couldn't be done better.

Post by Joe Rosevear
I am currently the keeper of about two dozen Slackware-running
computers for mostly students. I am the only person who does any
admin work on those computers.
Your situation, I'll bet, is rather different from mine.

Yes; I work at a university, managing dozens of mostly non-Slackware
(though still Linux) systems for a broad community of students,
faculty, researchers, and administrators. I work in a small team,
so everything I do needs to at least somewhat resemble what colleagues
would do in the same situation. There's no such thing as a "temporary"
solution here, since anything labelled temporary inevitably becomes
"production" at some point, so everything we do needs to stand up to
a production environment.

At home I manage a much smaller setup of mostly Slackware systems for
personal use. A much different situation yet again, but still a 24x7
operation which is counted on to be stable, secure, and always
available.

Post by Joe Rosevear
Right. It looks like I would, in fact, want to use
/etc/ssh/ssh_config, and I only need the KexAlgorithms line. I'm
guessing my first line should be "Host *", as I want this to apply to
all hosts. Is that how it works?

Yes, exactly.

Post by Joe Rosevear
I played with run level 4, but I don't use it. Instead, I set up
inittab to invoke /usr/local/bin/autologin.sh in this way: ...

I haven't used autologin, but you might be curious to look into kdm's
configuration options. I'm pretty sure that it also has an autologin
facility (which would give you the same functionality in runlevel 4).

I think that one of the advantages of run level 4, especially in your
environment is that if X gets killed for whatever reason, it
automatically just restarts. Add autologin to that, and it would just
get you right back to that desktop.

Post by Joe Rosevear
That's quite a list. I'll bet your admin work keeps you busy.

Most of what I listed are done once at installation, though (and a few
get repeated after package updates are applied, of course), but yes,
system administration is my full-time occupation. The home systems get
(a lot) less time devoted to them, but they're setup (and maintained)
to the same standards as the work systems. My documentation is done
in such a way that implementing the list I showed is just a matter
of copying and pasting commands. The next step up from that would
be something like Henrik has done, with custom packages to just deal
with them, but so far I haven't been compelled to implement that.
It just doesn't take that much time, and I'd have to do it manually
at least once with each OS upgrade anyway, to see what has changed,
what needs to be added, etc.

I used to use a script (frequently pointed at in this newsgroup,
though that was some years ago) that did the entire (Slackware)
installation, and of course took care of the bulk of post-installation
configuration, but I found it took me longer to maintain that
script for each new Slackware release than it does to just install
(admittedly with tagfiles on an NFS server, so not entirely manually).
The tagfiles also need to be updated with new releases, but that
doesn't take nearly as much time as maintaining my script did.

[Michael Black]

Post by Joe Rosevear
Howdy,
In a different post I described how I got my printer working.
Basically, I twiddled with Slackware's foomatic-rip filters. For more
http://joeslife.org/news
This raises a talking point. I wonder if my printer fix needs to be
included somehow in Slackware? I think, perhaps, it should at least be
listed under the heading of "You Might Want to Change This".

If you think something is missing, a bug or something left out as opposed
to something you are certain should be in there because you want it, you
should tell Slackware.

I was trying to get my old printer going with 14.2 a few months ago, and
there was no /dev/lp0 defined. A search uncovered a post here, someone
noticed soon after 14.2 came out. Simple oversight, or someone assuming
few are still using parallel port printers, but a problem for those
expecting it to be there. I don't know if anyone told Slackware, and I
didn't check if the "current" had been fixed, but that's the sort of thing
that is overlooked, and will remain until someone points it out.

These things happen. Reading the changelog over time can be interesting,
I've seen fixes show up that relate to things that were probably in there
for a long time. There are lots of fixes, real simple things, and someone
gets thanked for pointing the problem out.

Michael

[Mike Spencer]

Post by Michael Black
I was trying to get my old printer going with 14.2 a few months ago, and
there was no /dev/lp0 defined. A search uncovered a post here, someone
noticed soon after 14.2 came out. Simple oversight, or someone assuming
few are still using parallel port printers, but a problem for those
expecting it to be there. I don't know if anyone told Slackware, and I
didn't check if the "current" had been fixed, but that's the sort of thing
that is overlooked, and will remain until someone points it out.

Huh. I only have 14.2 on a testbed laptop, haven't tried printing.
But my old Brother HL 641 laser printer is still going strong using
lprng with a hand-crafted /etc/printcap. Sent to a DLink router that
has a parallel printer port. Tried CUPS the first distro I got it
with, couldn't make it drive the Brother printer. Never went back to
try again.

I guess going through the router doesn't reference /dev/lp0 but I
assumed that it would work were I to plug the printer in directly to
the host (with real parallel port or via a USB-> parallel adapter).
Both virtual printers (lp=***@192.168.0.1 and lp=/dev/lp0) are options
in /etc/printcap.

[Eef Hartman]

Post by Michael Black
I was trying to get my old printer going with 14.2 a few months ago, and
there was no /dev/lp0 defined. A search uncovered a post here, someone
noticed soon after 14.2 came out.

In my system loading the parallel printer kernel modules in
/etc/rc.d/rc.modules did the trick:
/sbin/modprobe parport_pc io=0x378 irq=7 dma=1
(I use this one and not the default as there possibly is a ZIP drive
too on that port)
/sbin/modprobe -q lp 2> /dev/null

BTW: the printer is a LaserJet 6MP and works with the standard CUPS
filter:
MakeModel HP LaserJet 6P/6MP - PostScript
DeviceURI parallel:/dev/lp0
etc.

[Michael Black]

Post by Eef Hartman

Post by Michael Black
I was trying to get my old printer going with 14.2 a few months ago, and
there was no /dev/lp0 defined. A search uncovered a post here, someone
noticed soon after 14.2 came out.

In my system loading the parallel printer kernel modules in
/sbin/modprobe parport_pc io=0x378 irq=7 dma=1
(I use this one and not the default as there possibly is a ZIP drive
too on that port)
/sbin/modprobe -q lp 2> /dev/null

Yes, Chick Tower at the time asked, and you supplied an answer, which is
what I used to fix my problem.

I don't change hardware enough to be good at this. I plugged in the
printer, and something was different from what I reemmbered, and then I
realized no /dev/lp0

I would think even at this point parallel printers are not uncommon. I
don't expect to come set up for that USB wifi adapter that I had from
eyars ago, too slow now to bother. Or that serial Wacom tablet I found,
probably never many of those running on Linux. But a parallel printer
isn't too antiquated, I picked this "new" refurbished computer because it
still had a parallel and serial port.

So maybe someone forgot, or maybe someone did think it was "too
antiquated" and left it off. But it wasn't something I was expecting.

It is the advantage of installing somewhat after a new release, other
people can find the problems.

Post by Eef Hartman
BTW: the printer is a LaserJet 6MP and works with
MakeModel HP LaserJet 6P/6MP - PostScript
DeviceURI parallel:/dev/lp0
etc.

Mine was an HP 4P, I got it at a Rotary Club sale in 2003, for fifteen
dollars. Sadly, having moved it and then got /dev/lp0 going, soemthing's
broken so I'm going to get a new laser printer. Way cheaper new than back
then, I can't decide which one to buy. And I don't expect a new one,
selling for around $100, will be as sturdy.

Michael

[Joe Rosevear]

Post by Michael Black

Post by Joe Rosevear
Howdy,
In a different post I described how I got my printer working.
Basically, I twiddled with Slackware's foomatic-rip filters. For more
http://joeslife.org/news
This raises a talking point. I wonder if my printer fix needs to be
included somehow in Slackware? I think, perhaps, it should at least be
listed under the heading of "You Might Want to Change This".

If you think something is missing, a bug or something left out as opposed
to something you are certain should be in there because you want it, you
should tell Slackware.
I was trying to get my old printer going with 14.2 a few months ago, and
there was no /dev/lp0 defined. A search uncovered a post here, someone
noticed soon after 14.2 came out. Simple oversight, or someone assuming
few are still using parallel port printers, but a problem for those
expecting it to be there. I don't know if anyone told Slackware, and I
didn't check if the "current" had been fixed, but that's the sort of thing
that is overlooked, and will remain until someone points it out.
These things happen. Reading the changelog over time can be interesting,
I've seen fixes show up that relate to things that were probably in there
for a long time. There are lots of fixes, real simple things, and someone
gets thanked for pointing the problem out.
Michael

Yes, you're right. I searched on on the 32-bit changelog on "Thanks".
I got 333 hits.

-Joe

[Grover Cleveland]

Post by Joe Rosevear
This raises a talking point. I wonder if my printer fix needs to be
included somehow in Slackware? I think, perhaps, it should at least be
listed under the heading of "You Might Want to Change This".
You Might Want to Change This -----------------------------

The rename command under Slackware is archaic. The rename command in
the Debuntu family is much more flexible. And it's a perl script,
which means it and its manpage are portable. For me this was a
15-minute fix.

[Joe Rosevear]

Post by Grover Cleveland

Post by Joe Rosevear
This raises a talking point. I wonder if my printer fix needs to be
included somehow in Slackware? I think, perhaps, it should at least be
listed under the heading of "You Might Want to Change This".
You Might Want to Change This -----------------------------

The rename command under Slackware is archaic. The rename command in
the Debuntu family is much more flexible. And it's a perl script,
which means it and its manpage are portable. For me this was a
15-minute fix.

Thank you for that information.

I looked it up to learn more and found this 2014 post to
alt.os.linux.slackware:

https://groups.google.com/forum/#!topic/alt.os.linux.slackware/QuKcuX3ik3s

-Joe

[Henrik Carlqvist]

Post by Joe Rosevear
What's on your list?

I used to have a written list with things to manually fix or mostly
customize on my Slackware installation. But then I replaced this list
with a directory filled with custom Slackware packages and I also
customized the Slackware installation scripts to also install my custom
packages last at installation.

I found that everything I needed to customize was able to being put in a
package created by makepkg. Those packages can contain things like
customized configuration files below /etc and/or the script
install/doinst.sh which is being run as root during package installation.

Example of such a package:

PACKAGE NAME: kdehome-14.2-noarch-hc1
COMPRESSED PACKAGE SIZE: 512
UNCOMPRESSED PACKAGE SIZE: 10K
PACKAGE LOCATION: /var/log/mount/slackware64/cus/kdehome-14.2-noarch-
hc1.tgz
PACKAGE DESCRIPTION:
FILE LIST:
./
etc/
etc/profile.d/
etc/profile.d/kde.csh
etc/profile.d/kde.sh

...and the customization of those files is:

-8<----------------------------------------------------------
# Added by henca to allow different versions of KDE to coexist
KDEHOME=$HOME/.kde_slack142
export KDEHOME
-8<----------------------------------------------------------

The above fix is for an environment where users with their home
directories on NFS servers might log in on machines with different
versions of Slackware. Without that fix, logging in to a newer version of
Slackware would probably break KDE for older versions of Slackware.

Some installation scripts need to consider if the package was installed
during first installation or at a later occasion. If I install custom ssh
settings in /etc/ssh on a running system I want to restart the ssh daemon
for the new settings to take effect:

-8<---------------------------------
#!/bin/sh

fgrep sshd /usr/local/etc/rc.d/*

if [ $? -ne 0 ]; then
/etc/rc.d/rc.sshd restart
fi
-8<---------------------------------

Yes, I also have my own directory for all the things that I start or
restart from rc.local...

regards Henrik