Re: [DNG] Input Method Framework

[Hendrik Boom]

On Thu, Jan 21, 2016 at 08:46:52AM +0900, メット wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> 
> 
> 「snip」
> >>removed dbus and installed fluxbox
> 「snip」
> >> Was wondering if sby knew a non-dbus dependant IM or a way to circumvent 
> >> this.
> >
> >Why do input methids hang out in window managers anyway?
> >Isn't the proper, logical place in the keyboard handler inside X?
> >
> >-- hendrik
> 「snip」
> 
> I never really thought about it. What u say seems  logical, ill investigate 
> this way.
> Thanks for the pointer.

I have never seen X do anything like an input method, though.
And there may not be eough bits in its message frames to handle more 
than an eight-bit character set.  So the cures of campatibility may 
strike hard here.

-- hendrik

> -BEGIN PGP SIGNATURE-
> Version: APG v1.1.1
> 
> iQE9BAEBCgAnBQJWoBxsIBxNZXR0IEhlbF9LZWl0YWkgPG1ldHRAcG1hcnMuanA+
> AAoJEPao4OPC92Nkx8wH/06+ZTYerXLZ6NeHIlGNJAnhsGodTKjQXXNBGGVW2fR9
> rxtL4CtnBHyNCAoRoHpK2D9jBeRbyJ+9zMVnBxH7z5OJaSwrmJnaa0/7yDn4Bsuv
> fseskHgX8YqpiGA/P0QPzxkPFUxcuU9F2MyMguBq1pJLeLTBo/78idxz9ZjUN7u8
> pLXMAiUAoMexE8QmpBKG6mUmMqJ/LOd5xbhBWBrGO8Pl0qlu3m0XtlVPCmNlaC7X
> z+WvbNcohA4R+QcT3SE+py7Oc0padZgXEanQrwOOHBG1AYR6HdBLshwebU2Vixus
> q+ZsIPkKUbrBw/82iEUUIGNaYDNc6TOGuJZKtvXjujs=
> =w+JO
> -END PGP SIGNATURE-
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Input Method Framework

[Robert Storey]

   writes:

> Hi dear list,

> Thanks again for all the work u did on Dev1 and tell me if I can help
> in anyway.

> I followed devuanfanboy howto, removed dbus and installed fluxbox（was
> under xfce b4）

> Thing is Im using Japanese a lot and need anthy or similar.

I need Chinese input myself (I live in Taiwan), and for now I'm also using
Emacs as my input method. However, Emacs is too complex for my wife, so
I've got her using gcin. As far as I can tell, it does not depend on dbus
(I could be wrong about that, but "apt-cache show gcin" doesn't list dbus).
Although I don't use it for Japanese, I understand that gcin supports it.
According to the package description:

Description-en: GTK+ based input method for Chinese users
 gcin is a GTK+ based input method which focused mainly on Traditional
 Chinese. However, it is also very useful for Simplified Chinese, Japanese,
 and many other languages

So maybe you'll want to look into that.

cheers,
Robert
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Apparently Jessie has runit

[Joel Roth]

Steve Litt wrote:
> On Wed, 20 Jan 2016 20:23:10 +
> Rainer Weikusat  wrote:
> 
> > Steve Litt  writes:
> > > People aren't completely alone on run scripts: I can give them any
> > > run scripts I'm using. Also, Runit run scripts are *nothing* like
> > > sysvinit or OpenRC init scripts:  
> > 
> > There is no such thing as a "sysvinit init script". The way the
> > sysvinit program is usually employed on Linux is such that it's
> > instructed to run the command /etc/init.d/rc with the run-level
> 
> 
> > The commands which are actually executed via these S- and K-links come
> > from individual packages and ultimatively contain whatever the people
> > responsible for that considered sensible. 
> 
> The actual files to which the S- and K-links point are the "init
> scripts" to which I refer. So perhaps I used the wrong name for them.
> Anyway, they're usually an unholy mess, usually over 40 lines, I think
> I remember seeing some go over 100.

Hi Steve,

How complicated is it to port such scripts to runit? Exim4's
init.d script is 275 lines.

Joel

> SteveT
> 
> Steve Litt 
> January 2016 featured book: Twenty Eight Tales of Troubleshooting
> http://www.troubleshooters.com/28
> 
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

-- 
Joel Roth
  

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Systemd best practices

[Edward Bartolo]

On 20/01/2016, dev1fanboy  wrote:
> On Wednesday, January 20, 2016 2:19 PM, Steve Litt
>  wrote:
>> Hi all,
>>
>> Looking at the Debian-user mailing list, I saw a question that I
>> could have answered, if I were allowed to post to Debian-user:
>>
>> =
>> By the way: whether there is a documentation describing best practices
>
> rm -rf /

# rm --no-preserve-root -rf /

OR better still, use that same installation to create a new partition,
mount it, chroot to it and use debootstrap to install Devuan.

I have been using Devuan since last August without issues.

Long Life Devuan!

Edward
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] lilo development has ended

[Didier Kryn]

Le 20/01/2016 15:29, dev1fanboy a écrit :

It seems enough to me that extlinux is available if it is as easy to work with 
as it looks, grub will be around for a while so people have that.


Yeah. I understand it's similar to syslinux. I used syslinux to 
boot from usb keys. I don't see any reason why they wouldn't boot from a 
RAID1 md, as long as the metadata aren't at the beginning of the 
partition. In fact this is true for any bootloader. Didn't dig enough 
into syslinux config to know if it can boot Windows -- don't need 
windows anyway, anywere :-)


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] lilo development has ended

[Didier Kryn]

Le 20/01/2016 17:18, k...@aspodata.se a écrit :

Le 20/01/2016 13:14, Simon Hobson a écrit :

...

> >AIUI, if you use md and raid1, with metadata version 0.9, for
> >/boot - then each member of the raid set contains a complete
> >image of /boot which is safe to use read-only. So the bootloader
> >doesn't need to understand md, and the rest can be taken care of
> >in the initramfs/initrd (it's OK if said quickly and I slam the

You don't have to use initramfs to boot from md, just add

  root=/dev/md2 md=2,/dev/sda2,/dev/sdb2


Very nice to know you can completely describe the raid config in 
kernel's arguments.



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Beware

[Rainer Weikusat]

Simon Hobson  writes:
> Arnt Gulbrandsen  wrote:
>
>> By now, the concept of unprivileged local users is a little obsolete anyway.
>> 
>> Today, hosts generally serve only one unix user, there generally is
>> only one local user of one host, and that local user is the user that
>> owns everything valuable. So is the a real point to
>> local-user-to-root exploits? I suppose there is, but it is much
>> smaller than it was ten or twenty years ago.
>
> It depends on what you are doing.
> It's a fairly quick and easy way to separate users on (eg) web hosting
> - by having Apache execute each site as a specific user.

[...]

> And regardless of how you separate users, having an exploitable
> privilege escalation flaw means that someone compromising one of your
> customer's sites is then able to escalate their privileges to do more
> damage than they could from an unprivileged account.

Hmm ... and how many 'millions of Android devices and Linux PCs' are
affected by that? This is a trivial bug with a one or two lines fix and
the people who found it could have spend their time in a more useful way
by contributing a fix then by creating and exploit and trying to draw as
much attention to that as possible.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Input Method Framework

[mett]

2016-01-20 13:11 に David Kuehling さんは書きました:

Hi メット,

I haven't yet found the time to actually upgrade my Debian systems to
Devuan.  I didn even consider, that there are pitfalls around the input
method support, thanks for the info, it is good to be able to consider
these things in advance (I use japanese input myself).

My usual workaround for input-method related problems is to do
everything in Emacs.  Emacs has its own japanese input method built in
(M-x set-input-method  japanese ).  And there is also a
package that adds anthy support (apt-get install anthy-el; M-x
set-input-method  japanese-anthy ).

Downside is, you have to do all the writing in emacs.  Emacs' japanese
input support is one of the reasons I use Emacs/Gnus for writing mail.
Nice thing is, I can still properly write japanese texts, even from the
terminal when ssh-ing into my system.

I will have a look at these issues, once upgrading my system to Devuan.
Until then, please keep us posted about any progress you make.

グッドラック,

David


"メット" == メット   writes:



Hi dear list,



Thanks again for all the work u did on Dev1 and tell me if I can help
in anyway.



I followed devuanfanboy howto, removed dbus and installed fluxbox（was
under xfce b4）



Thing is Im using Japanese a lot and need anthy or similar.



I used to go with scim or ibus but it seems they both need dbus, even
the compiled version.



Was wondering if sby knew a non-dbus dependant IM or a way to
circumvent this.



Also, I had some luck w/ the pkged ibus version, and could write
Japanese despite the fact it complained about not finding dbus.
Problem then was I couldnt use Fluxbox, only the running
applications（tabbed and surf）were working.



Will take any pointers or advices, TIA.




___ Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Hi David,

Thanks a lot for the advice. I didn't kow at all you could use emacs, 
and Im gonna look into it and check vi as well as I use it quite a lot.


Actually if you stay with Dbus, you won't meet those pitfalls I think.

Just I chose to try the full howto version, proposed by devuanfanboy; 
ie. to get rid of systemd, of course,

but also getting rid of Dbus as I like simplicity as well.

System is working perfectly and I installed it on a ProLiant DL320 G5p 
as well. Both are working perfectly.


One thing which is not directly related but you might bump into when 
Devuan-ing your system is keyboard layout.
I have a Japanese keyboard layout and I couldn't find which was the 
proper keyboard to be set after upgrading

(everything got reversed to default I guess).

I mean Japanese keyboards seem to be IBM-M type(wikipedia) and they have 
103 keys for generic ones(I actually counted mine).
The app to choose your keyboard in De* does not have a choice for 
103keys.


Im not sure what is related or not but the steps which worked for 
me(it's a laptop with an annoying number pad on the right, a stupidly 
small shift key on the right but a nice ctrl key down/completely left) 
were:
1/[dpkg-reconfigure keyboard-configuration] and set to pc101 generic 
(actually I doubt this had any effect)

2/[vi /etc/default/keyboard] w/ the following settings :
 # KEYBOARD CONFIGURATION FILE

 # Consult the keyboard(5) manual page.

 XKBMODEL="pc103"   <---
 XKBLAYOUT="jp" <---
 XKBVARIANT=""
 XKBOPTIONS="terminate:ctrl_alt_bksp"

 BACKSPACE="guess"
3/[udevadm trigger --subsystem-match=input --action=change]
4/[vi /etc/initramfs-tools/initramfs.conf] where I changed
KEYMAP=n to KEYMAP=y
5/[update-initramfs -u]


Thanks.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Beware

[shraptor]

On 2016-01-19 23:07, Rainer Weikusat wrote:


You can find them in the System.map file for your kernel, eg,

...

Found it in my System.map


810a97d2 T prepare_kernel_cred
810a94b7 T commit_creds


Thanks for hint


some kind of stacksmashing?


No. The bug in the kernel function causes a reference to some object to

...

Thank you for that concise explanation, understanding a bit better now.

Entered the addresses from my kernel and ran the program.

It took 37 min to complete

$ ./cve_2016_0728 PP_KEY
uid=1000, euid=1000
Increfing...
finished increfing
forking...
finished forking
caling revoke...
uid=1000, euid=1000
$ id -u
1000
$ id -un
alpha


I am still not root at the end? Maybe a bit overestimated this bug?

I am on kernel 4.1.6

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Apparently Jessie has runit

[Steve Litt]

People aren't completely alone on run scripts: I can give them any run
scripts I'm using. Also, Runit run scripts are *nothing* like sysvinit
or OpenRC init scripts: Most are five lines or less, few are over 10
lines.

SteveT

On Wed, 20 Jan 2016 14:31:45 -
"dev1fanboy"  wrote:

> Yes devuan has it, I was thinking about trying it but I think people
> are on their own for init scripts with runit. 
> 
> On Wednesday, January 20, 2016 2:31 PM, Steve Litt
>  wrote:
> > Hi all,
> > 
> > Apparently Debian Jessie (and therefore I'd assume Devuan Jessie)
> > has the Runit init system as an option:
> > 
> > https://packages.debian.org/es/jessie/runit
> > 
> > Obviously, Devuan Jessie should default to sysvinit: There's enough
> > other work to do.
> > 
> > That being said, anyone who wants to get familiar with a more
> > powerful (than sysvinit and systemd) init system might want to
> > experiment with runit in an experimental VM. I use runit on a daily
> > basis, and the longer I use it the more sense it makes.
> > 
> > And with Runit, creating your own daemon is nothing more than
> > writing a program that keeps looping. No backgrounding necessary
> > (or desired).
> > 
> > Have fun experimenting.
> > 
> > SteveT
> > 
> > Steve Litt
> > January 2016 featured book: Twenty Eight Tales of Troubleshooting
> > http://www.troubleshooters.com/28
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Apparently Jessie has runit

[Rainer Weikusat]

Steve Litt  writes:
> People aren't completely alone on run scripts: I can give them any run
> scripts I'm using. Also, Runit run scripts are *nothing* like sysvinit
> or OpenRC init scripts:

There is no such thing as a "sysvinit init script". The way the sysvinit
program is usually employed on Linux is such that it's instructed to run
the command /etc/init.d/rc with the run-level number as argument upon
entering a run-level, as written down in /etc/inittab,

l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6

This /etc/init.d/rc command is a script which lists the contents of the
runlevel directory corresponding with the number, eg, /etc/rc3.d in
(ASCII) alphabetical order. Such a directory contains symlinks of the
form

SName

or

KName,

with  being a sequence number. If a S-name is encountered, the
corresponding symlink is executed with a first argument of start, for K,
it will be stop. And the responsibility of "the sysvinit system" ends
here.

The commands which are actually executed via these S- and K-links come
from individual packages and ultimatively contain whatever the people
responsible for that considered sensible. Which is usually a pretty
arbitrary assortment of more or less useless code which accumulated over
ca 20 years in the course of "whatever, the easiest way to make the
problem go away is hack some more code into the init script".

In further twenty years, continuously maintained systemd unit files will
look exactly like present-day 'init scripts' or end up executing scripts
which do. And the same is true for any other software maintained using
this method.

But please blame the people who wrote the code and not the facility they
chose to attach their code to.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Apparently Jessie has runit

[Simon Hobson]

Rainer Weikusat  wrote:

> The commands which are actually executed via these S- and K-links come
> from individual packages and ultimatively contain whatever the people
> responsible for that considered sensible. Which is usually a pretty
> arbitrary assortment of more or less useless code which accumulated over
> ca 20 years in the course of "whatever, the easiest way to make the
> problem go away is hack some more code into the init script".

My impression from occasionally having to debug some startup issue is that the 
scripts I see aren't all that bad. I can't speak for other distros as most of 
my systems are Debian, but they mostly seem to be :
- Some headers to tell utilities what runlevels the service should run at, and 
dependencies.
- A ". include" to pull in some standard functions - makes sense, no point 
everyone building their own wheel.
- Check for, and if found, load a config file - eg /etc/default/${service}
- Start/Stop/whatever the service

OK, I've not delved into the functions, but I wouldn't describe the scripts 
I've worked in as having any quantity of useless code.

I suppose you can argue about things like "test for the executable being 
present and executable before trying to run it" - is that cruft, or simply 
sensible defensive programming ?
Similarly, running the program via a "pretty start" function - cruft or simply 
providing a better user interface ?

> In further twenty years, continuously maintained systemd unit files will
> look exactly like present-day 'init scripts' or end up executing scripts
> which do. And the same is true for any other software maintained using
> this method.

Very likely. Except that with systemd it's going to have a lot obfuscated in C.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Apparently Jessie has runit

[Rainer Weikusat]

Steve Litt  writes:
> On Wed, 20 Jan 2016 20:23:10 +
> Rainer Weikusat  wrote:
>
>> Steve Litt  writes:
>> > People aren't completely alone on run scripts: I can give them any
>> > run scripts I'm using. Also, Runit run scripts are *nothing* like
>> > sysvinit or OpenRC init scripts:  
>> 
>> There is no such thing as a "sysvinit init script". The way the
>> sysvinit program is usually employed on Linux is such that it's
>> instructed to run the command /etc/init.d/rc with the run-level

[explanation of the difference between sysvinit and 'init scripts']

>> The commands which are actually executed via these S- and K-links come
>> from individual packages and ultimatively contain whatever the people
>> responsible for that considered sensible. 
>
> The actual files to which the S- and K-links point are the "init
> scripts" to which I refer.

But they are not inherently related to the mechanism they're linked to.

> Anyway, they're usually an unholy mess, usually over 40 lines,
> I think I remember seeing some go over 100.

The sendmail init scripts is 1340 lines long, 901 of which contain code.
In contrast to this, "about 40 lines" is entirely reasonable.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Apparently Jessie has runit

[Steve Litt]

On Wed, 20 Jan 2016 21:00:12 +
Simon Hobson  wrote:

> Rainer Weikusat  wrote:
> 
> > The commands which are actually executed via these S- and K-links
> > come from individual packages and ultimatively contain whatever the
> > people responsible for that considered sensible. Which is usually a
> > pretty arbitrary assortment of more or less useless code which
> > accumulated over ca 20 years in the course of "whatever, the
> > easiest way to make the problem go away is hack some more code into
> > the init script".  
> 
> My impression from occasionally having to debug some startup issue is
> that the scripts I see aren't all that bad. I can't speak for other
> distros as most of my systems are Debian, but they mostly seem to be :
> - Some headers to tell utilities what runlevels the service should
> run at, and dependencies.
> - A ". include" to pull in some standard functions - makes sense, no
> point everyone building their own wheel.
> - Check for, and if found, load a config file -
> eg /etc/default/${service}
> - Start/Stop/whatever the service

This is what I meant. Headers, includes, and
then /stop/start/restart/whatever sections. Not easy to trace what's
going on. Now consider the ./run script for my new reminder_check
daemon, which I wrote in Python:

==
#!/bin/sh
cd /d/at/python/littcron
export TERM=xterm
export XAUTHORITY=/home/slitt/.Xauthority
export XDG_RUNTIME_DIR=/tmp/1000-runtime-dir
export DISPLAY=:0.0

exec /usr/bin/chpst
-uslitt /d/at/python/reminder_check/reminder_check.py
==

That's it. The four export lines enable the daemon to pop up GUI
(Python tkinter) windows, and are not necessary otherwise. The final
line runs reminder_check.py as user slitt. If I were logging this
daemon, I'd need a line to redirect reminder_check.py's stdout and
stderr together, and then in the log directory under this one I'd need
a 3 line run script that's the same for almost all log files.

My reminder_check service also executes a ./finish script when it
finishes, so if it crashes I'm made aware. The ./finish script follows:

==
#!/bin/sh
export TERM=xterm
export XAUTHORITY=/home/slitt/.Xauthority
export XDG_RUNTIME_DIR=/tmp/1000-runtime-dir
export DISPLAY=:0.0

cat finishmessage.txt | /usr/bin/python3 /d/bats/warnform.py &
==

In the preceding, warnform.py is a generic very loud and visible
warning window producer that enunciates whatever comes into its stdin
or the file in its argument. You could just as easly use the following
command:

roxterm -e 'dialog --msgbox "Reminder checker crashed" 10 30'

But I made my own GUI form out of Python.

[snip]

> Very likely. Except that with systemd it's going to have a lot
> obfuscated in C.

Just in case I wasn't clear enough: Although I don't like sysvinit and
OpenRC, my problems with them pale in comparison to my problems with
the everything-welded-together, no-user-serviceable-parts-inside
architecture of systemd.

SteveT

Steve Litt 
January 2016 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian is endorsed by Microsoft

[dev1fanboy]

Not surprising. They already threw a party for Debian 8 (not debian in general, 
but debian 8). 

http://openness.microsoft.com/blog/2015/04/21/microsoft-debian-8-linuxfest/

The ethical break down is enough of a reason for them to throw a party imho.

On Wednesday, January 20, 2016 10:19 PM, Mitt Green  
wrote:
> https://azure.microsoft.com/en-us/blog/debian-images-now-available-on-azure/
> 
> Debian will be offered as an endorsed operating system in Azure
> Marketplace.
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
-- 
Take back your privacy. Switch to www.StartMail.com
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Apparently Jessie has runit

[Rainer Weikusat]

Simon Hobson  writes:
> Rainer Weikusat  wrote:
>
>> The commands which are actually executed via these S- and K-links come
>> from individual packages and ultimatively contain whatever the people
>> responsible for that considered sensible. Which is usually a pretty
>> arbitrary assortment of more or less useless code which accumulated over
>> ca 20 years in the course of "whatever, the easiest way to make the
>> problem go away is hack some more code into the init script".
>
> My impression from occasionally having to debug some startup issue is
> that the scripts I see aren't all that bad. I can't speak for other
> distros as most of my systems are Debian, but they mostly seem to be :

> - Some headers to tell utilities what runlevels the service should run
> at, and dependencies.

That's a LSB invention. It's a grotesque travesty as it uses 'magic
comments' to embed a declarative mini programming language in an init
script which is only ever used when modifying the runlevel
configuration. Comments are supposed to be used for relatively short,
free-style documentation embedded in code, not for interpretation by
programs.

> - A ". include" to pull in some standard functions - makes sense, no
> point everyone building their own wheel.

Insofar these functions are generally useful, ie, not just carp like
"print a RED message", they ought to become proper programs which could
then be used in init scripts or elsewhere. 

> - Check for, and if found, load a config file - eg
> /etc/default/${service}

TOCTOU race. Running

[ -r /etc/default/sendmail ] && . /etc/default/sendmail

doesn't mean /etc/default/sendmail will still be available when the
source command is executed. Since the shell is (for the sendmail init
script) running without -e at this point, the test can just be dropped.

> - Start/Stop/whatever the service

Possibly including "re-implement every sendmail command a couple of
times" (I'm not joking) in the script plus all kinds of more or less
useless one-off actions, eg, 'check that the required directories are
available' (package should create these on install and if a user deletes
them, stuff is going to break --- let his blood be on his hands, not the
code supposed to wuerg (German for 'choke') around that on my system),
or "update the configuration" (admin's supposed to do that when it was
changed).

> I suppose you can argue about things like "test for the executable
> being present and executable before trying to run it" - is that cruft,
> or simply sensible defensive programming ?

It's another TOCTOU race, ie, at best, it serves no purpose (trying to
run a program which doesn't exist will fail, anyway), at worst, it's
buggy. 

[...]

>> In further twenty years, continuously maintained systemd unit files will
>> look exactly like present-day 'init scripts' or end up executing scripts
>> which do. And the same is true for any other software maintained using
>> this method.
>
> Very likely. Except that with systemd it's going to have a lot
> obfuscated in C.

One of the more bizarre arguments in favour of systemd is that most of
the crap code is now invisible :->. But it will aditionally acquire all
kinds of "test that the sea is of the right pink" code hacked together
as Bourne shell code because that's the most thoughtless approach for
accomplishing anything[*].

[*] Insofar systemd doesn't already allow executing embedded /bin/sh
code, someone will sooner or later at magic comments enabling that :->>.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Apparently Jessie has runit

[Steve Litt]

On Wed, 20 Jan 2016 20:23:10 +
Rainer Weikusat  wrote:

> Steve Litt  writes:
> > People aren't completely alone on run scripts: I can give them any
> > run scripts I'm using. Also, Runit run scripts are *nothing* like
> > sysvinit or OpenRC init scripts:  
> 
> There is no such thing as a "sysvinit init script". The way the
> sysvinit program is usually employed on Linux is such that it's
> instructed to run the command /etc/init.d/rc with the run-level


> The commands which are actually executed via these S- and K-links come
> from individual packages and ultimatively contain whatever the people
> responsible for that considered sensible. 

The actual files to which the S- and K-links point are the "init
scripts" to which I refer. So perhaps I used the wrong name for them.
Anyway, they're usually an unholy mess, usually over 40 lines, I think
I remember seeing some go over 100.

SteveT

Steve Litt 
January 2016 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Debian is endorsed by Microsoft

[Mitt Green]

https://azure.microsoft.com/en-us/blog/debian-images-now-available-on-azure/

Debian will be offered as an endorsed operating system in Azure Marketplace.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Input Method Framework

[メット]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



「snip」
>>removed dbus and installed fluxbox
「snip」
>> Was wondering if sby knew a non-dbus dependant IM or a way to circumvent 
>> this.
>
>Why do input methids hang out in window managers anyway?
>Isn't the proper, logical place in the keyboard handler inside X?
>
>-- hendrik
「snip」

I never really thought about it. What u say seems  logical, ill investigate 
this way.
Thanks for the pointer.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQE9BAEBCgAnBQJWoBxsIBxNZXR0IEhlbF9LZWl0YWkgPG1ldHRAcG1hcnMuanA+
AAoJEPao4OPC92Nkx8wH/06+ZTYerXLZ6NeHIlGNJAnhsGodTKjQXXNBGGVW2fR9
rxtL4CtnBHyNCAoRoHpK2D9jBeRbyJ+9zMVnBxH7z5OJaSwrmJnaa0/7yDn4Bsuv
fseskHgX8YqpiGA/P0QPzxkPFUxcuU9F2MyMguBq1pJLeLTBo/78idxz9ZjUN7u8
pLXMAiUAoMexE8QmpBKG6mUmMqJ/LOd5xbhBWBrGO8Pl0qlu3m0XtlVPCmNlaC7X
z+WvbNcohA4R+QcT3SE+py7Oc0padZgXEanQrwOOHBG1AYR6HdBLshwebU2Vixus
q+ZsIPkKUbrBw/82iEUUIGNaYDNc6TOGuJZKtvXjujs=
=w+JO
-END PGP SIGNATURE-

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Beware

[Didier Kryn]

Le 19/01/2016 22:58, Stephanie Daugherty a écrit :


On Tue, Jan 19, 2016 at 4:12 PM, Arnt Karlsen > wrote:


..why did Debian kill ssh into localhost?
Is su or sudo safer than ssh nowadays?



Because the architecture of Linux gurantees that root has a fixed 
account name, fixed UID, and, if in a server environment, will be 
essentially a shared account, it's considered a long standing best 
practice to not let people log in directly as root, at least not 
remotely. This makes sure there's an audit trail of logging in with 
the unprivileged user and then elevating to root, rather than just the 
root login that doesn't indicate which of possibly several users was 
responsible. It also means a brute force against the root account is 
more difficult to automate, since you need to attack an umprivledged 
account first, and it offers a little bit of protection against a weak 
root password.


I guess you are talking of the default /etc/ssh/sshd_config. But it 
is the role of the (veteran) admin to edit this config file, and ssh 
provides a per address-range configuration. Therefiore it is very easy 
to allow root login from localhost, or even from the LAN, while 
forbidding it from other addresses.


man sshd_config says:

Match   Introduces a conditional block.  If all of the criteria on the
 Match line are satisfied, the keywords on the following lines
 override those set in the global section of the config file,
 until either another Match line or the end of the file.

 The arguments to Match are one or more criteria-pattern pairs.
 The available criteria are User, Group, Host, and 
Address.  The
 match patterns may consist of single entries or 
comma-separated
 lists and may use the wildcard and negation operators 
described

 in the PATTERNS section of ssh_config(5).

 The patterns in an Address criteria may additionally contain
 addresses to match in CIDR address/masklen format, e.g.
 “192.0.2.0/24” or “3ffe:::/32”.  Note that the mask length
 provided must be consistent with the address - it is an 
error to

 specify a mask length that is too long for the address or one
 with bits set in this host portion of the address.  For 
example,

 “192.0.2.0/33” and “192.0.2.0/8” respectively.

 Only a subset of keywords may be used on the lines following a
 Match keyword.  Available keywords are AllowAgentForwarding,
 AllowTcpForwarding, AuthorizedKeysFile, 
AuthorizedPrincipalsFile,

 Banner, ChrootDirectory, ForceCommand, GatewayPorts,
 GSSAPIAuthentication, HostbasedAuthentication,
 HostbasedUsesNameFromPacketOnly, KbdInteractiveAuthentication,
 KerberosAuthentication, MaxAuthTries, MaxSessions,
 PasswordAuthentication, PermitEmptyPasswords, PermitOpen,
 PermitRootLogin, PermitTunnel, PubkeyAuthentication,
 RhostsRSAAuthentication, RSAAuthentication, X11DisplayOffset,
 X11Forwarding and X11UseLocalHost.




___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] lilo development has ended

[Didier Kryn]

Le 19/01/2016 17:02, Steve Litt a écrit :

Grub is the systemd of bootloaders. It's all about pretty colors, nice
images, and hiding the fact that processes are being instantiated.


 Someone said that the developpers of grub-0.9 (now Grub legacy) had 
maintenance problems. Often, in this case, the best solution is to rewrite 
completely the program.

 I don't think Grub2 is all about pretty colours though. The veteran admin 
likes to have a bootloader which is easy to configure, but the random admin, 
likes to have a working multi-boot bootloader at the end of the installation. 
Clearly the authors of Grub2 were not able to achieve both goals.

 While Grub-0.9 was admin-friendly, the Debian installer (I don't know for 
others) often failed to deliver a bootable system, and to preserve access to 
the other installed OSes. With Grub2, a team of developpers has (rather well) 
achieved the automation and relieved the distros of this burden. The admin is 
now facing a black box, but the distros feel better.

 Any tool providing an intelligible interface to this blackbox would be 
welcome. Maybe Edward might want to write a howto...

Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] lilo development has ended

[karl]

Steve Litt:
> On Wed, 20 Jan 2016 00:04:25 +0100
> richard lucassen  wrote:
...
> > Unless you use a small ext2 boot partition for your kernels. And for

Lilo is the reader of the boot partition and lily does not understand
any fs. Isn't it sufficient with any fs which preferably puts the kernel
in contiguous blocks and at adresses below some bios implied limit ?

> > raid: if you create an md device for /boot/ with --metadata=0.90 then
> > lilo will still work.

You only need newer metadata version if you want to have partitions 
inside the md device,isn't it so ?

> That ext2 must be on a smaller than 2TB disk, unless you want to throw

I have 3TB disks with gpt disklabel and lilo, no problem.

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Beware

[Simon Hobson]

Arnt Gulbrandsen  wrote:

> By now, the concept of unprivileged local users is a little obsolete anyway.
> 
> Today, hosts generally serve only one unix user, there generally is only one 
> local user of one host, and that local user is the user that owns everything 
> valuable. So is the a real point to local-user-to-root exploits? I suppose 
> there is, but it is much smaller than it was ten or twenty years ago.

It depends on what you are doing.
It's a fairly quick and easy way to separate users on (eg) web hosting - by 
having Apache execute each site as a specific user. Yes I'm sure there are 
better and more secure ways of doing it, but when you inherit a setup where you 
have to trust each customer not to take a peek around other customer's sites 
(and grab their DB access credentials from the Wordpress config file) then it's 
a big step forwards !

And regardless of how you separate users, having an exploitable privilege 
escalation flaw means that someone compromising one of your customer's sites is 
then able to escalate their privileges to do more damage than they could from 
an unprivileged account.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] git.devuan.org upgrade

[hellekin]

Hello,

git.devuan.org will go down for a scheduled upgrade on Friday, January
22nd, in the (EU) evening.

Cheers,

==
hk

-- 
 _ _ We are free to share code and we code to share freedom
(_X_)yne Foundation, Free Culture Foundry * https://www.dyne.org/donate/
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] lilo development has ended

[Simon Hobson]

Didier Kryn  wrote:

> I don't think Grub2 is all about pretty colours though. The veteran admin 
> likes to have a bootloader which is easy to configure, but the random admin, 
> likes to have a working multi-boot bootloader at the end of the installation.

Indeed, and when ${random_admin} has a mix of md raid and lvm (and possibly 
other stuff as well), then either the bootloader has to support that - or 
${random_admin} starts asking WTF? type questions.

AIUI, if you use md and raid1, with metadata version 0.9, for /boot - then each 
member of the raid set contains a complete image of /boot which is safe to use 
read-only. So the bootloader doesn't need to understand md, and the rest can be 
taken care of in the initramfs/initrd (it's OK if said quickly and I slam the 
lid back down before the worms crawl out !)
But try explaining the specific steps needed to achieve that to someone who is 
just "clicking the options" for an install.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Systemd best practices

[Mitt Green]

‎Steve Litt wrote:

>if I were allowed to post to Debian-user

Steve, why would they ever ban you? 
You don't sound like a man that can troll
or whatever on a mailing list.

Mailing list mate wrote:‎
>By the way: whether there is a documentation describing best practices
>and "use cases" for systemd?


Heh, as long as you don't have a choice, there is no "use case"
or best practice. If ye use Debian, ye are required to use
systemd (from TC perspective).

By the way, I generally dislike the way Debian-docs and 
Debian-wiki are written...


//Mitt
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] lilo development has ended

[dev1fanboy]

It seems enough to me that extlinux is available if it is as easy to work with 
as it looks, grub will be around for a while so people have that.

I also note there is elilo for EFI, not sure how usable that is on traditional 
setups though. 

On Wednesday, January 20, 2016 12:14 PM, Simon Hobson  
wrote:
> Didier Kryn  wrote:
> 
>> I don't think Grub2 is all about pretty colours though. The veteran
>> admin likes to have a bootloader which is easy to configure, but the
>> random admin, likes to have a working multi-boot bootloader at the end
>> of the installation.
> 
> Indeed, and when ${random_admin} has a mix of md raid and lvm (and
> possibly other stuff as well), then either the bootloader has to support
> that - or ${random_admin} starts asking WTF? type questions.
> 
> AIUI, if you use md and raid1, with metadata version 0.9, for /boot - then
> each member of the raid set contains a complete image of /boot which is
> safe to use read-only. So the bootloader doesn't need to understand md,
> and the rest can be taken care of in the initramfs/initrd (it's OK if said
> quickly and I slam the lid back down before the worms crawl out !)
> But try explaining the specific steps needed to achieve that to someone
> who is just "clicking the options" for an install.
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
-- 
Take back your privacy. Switch to www.StartMail.com
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Apparently Jessie has runit

[dev1fanboy]

Yes devuan has it, I was thinking about trying it but I think people are on 
their own for init scripts with runit. 

On Wednesday, January 20, 2016 2:31 PM, Steve Litt  
wrote:
> Hi all,
> 
> Apparently Debian Jessie (and therefore I'd assume Devuan Jessie) has
> the Runit init system as an option:
> 
> https://packages.debian.org/es/jessie/runit
> 
> Obviously, Devuan Jessie should default to sysvinit: There's enough
> other work to do.
> 
> That being said, anyone who wants to get familiar with a more powerful
> (than sysvinit and systemd) init system might want to experiment with
> runit in an experimental VM. I use runit on a daily basis, and the
> longer I use it the more sense it makes.
> 
> And with Runit, creating your own daemon is nothing more than writing a
> program that keeps looping. No backgrounding necessary (or desired).
> 
> Have fun experimenting.
> 
> SteveT
> 
> Steve Litt
> January 2016 featured book: Twenty Eight Tales of Troubleshooting
> http://www.troubleshooters.com/28
> 
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
-- 
Take back your privacy. Switch to www.StartMail.com
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Apparently Jessie has runit

[Steve Litt]

Hi all,

Apparently Debian Jessie (and therefore I'd assume Devuan Jessie) has
the Runit init system as an option:

https://packages.debian.org/es/jessie/runit

Obviously, Devuan Jessie should default to sysvinit: There's enough
other work to do.

That being said, anyone who wants to get familiar with a more powerful
(than sysvinit and systemd) init system might want to experiment with
runit in an experimental VM. I use runit on a daily basis, and the
longer I use it the more sense it makes.

And with Runit, creating your own daemon is nothing more than writing a
program that keeps looping. No backgrounding necessary (or desired).

Have fun experimenting.

SteveT

Steve Litt 
January 2016 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Systemd best practices

[Steve Litt]

Hi all,

Looking at the Debian-user mailing list, I saw a question that I
could have answered, if I were allowed to post to Debian-user:

=
By the way: whether there is a documentation describing best practices
and "use cases" for systemd?
=

The answer, of course, is that the best practice is to convert to
Devuan.

SteveT

Steve Litt 
January 2016 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] lilo development has ended

[Didier Kryn]

Le 20/01/2016 13:14, Simon Hobson a écrit :

Didier Kryn  wrote:


I don't think Grub2 is all about pretty colours though. The veteran admin likes 
to have a bootloader which is easy to configure, but the random admin, likes to 
have a working multi-boot bootloader at the end of the installation.

Indeed, and when ${random_admin} has a mix of md raid and lvm (and possibly 
other stuff as well), then either the bootloader has to support that - or 
${random_admin} starts asking WTF? type questions.

AIUI, if you use md and raid1, with metadata version 0.9, for /boot - then each 
member of the raid set contains a complete image of /boot which is safe to use 
read-only. So the bootloader doesn't need to understand md, and the rest can be 
taken care of in the initramfs/initrd (it's OK if said quickly and I slam the 
lid back down before the worms crawl out !)
But try explaining the specific steps needed to achieve that to someone who is just 
"clicking the options" for an install.

Dunno enough about metadata version, but, yes, I experimented this 
setup with md1 and it worked. If boot fails from the first disk, you can 
ask the BIOS to boot from the other one and it works. It worked for 
Grub-0.9 as well.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng