Re: running arecord via ssh

2018-05-17 Thread mick crane

On 2018-05-16 18:10, Pierre Frenkiel wrote:

hi,
I try to record some old vinyls with arecord, the output being
sent to my desktop via a radio transmitter/receiver couple.

On the desktop xterm window, its works perfectly, but if I run arecord 
via

a ssh connection:

1/ from an other computer:
  ssh mydesktop arecord_command
2/ in a ssh xterm window:
  ssh mydesktop
  arecord_command

I get an empty file

Is really arecord incompatible with ssh?

best regards,


possibly it wants X for some reason and it is not on the ssh client.
try, if windows, Xming, see if it works.

mick




--
Key ID4BFEBB31



Re: lightdm (testing): Long waiting time after login

2018-05-17 Thread Dino

On 17.05.2018 00:43 Ben Caradoc-Davies wrote:

On 16/05/18 19:28, w...@hllmnn.de wrote:
I just did a fresh install of testing with XFCE. After entering the 
login

credentials the screen was black for 30-60 seconds before the desktop
environment showed up. Assuming a bug in XFCE, I performed another 
fresh install
with MATE, but a similar effect occured: after login the background 
image is

shown for 30-60 seconds before the desktop is fully loaded.


What happens if you wiggle your mouse or provide keyboard activity 
while waiting? For example, if you wiggle your mouse vigorously for 
two seconds or press the Alt key 20 times? Does the wait end sooner?


In Linux 4.16, the getrandom system call (without the GRND_NONBLOCK 
flag) blocks until sufficient entropy is available in the pool. This 
is the documented behaviour, and Linux 4.16 now enforces it to fix 
CVE-2018-1108. This has caught out several services that try to use 
getrandom (without the GRND_NONBLOCK flag) at early boot, including 
plymouth (via fontconfig) and gdm3. What you see might have the same 
cause. For details of my investigation, see:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897572

Wiggling your mouse or providing keyboard activity adds entropy to the 
pool. If this reduces the waiting time, you might be affected by the 
same bug.


Kind regards,


Hi Ben,

Yes, you're right! When I wiggle the mouse the wait ends sooner. Indeed, 
if I don't move the mouse at all and don't press any key the screen just 
stays blank (I waited approx. 5 minutes and it still was black).


I attached the output of dmesg | grep "random". As you can see, "crng 
init done" appears after the 5 minutes I waited.


Since there is no "splash" in my kernel command line in grub, I added 
"noplymouth" to it, but that didn't help. Maybe it's another package 
that calls getrandom without GRND_NONBLOCK. Let me know if I can support 
the investigation somehow.


Kind regards,
Dino
[0.00] random: get_random_bytes called from start_kernel+0x94/0x478 with crng_init=0
[4.426793] random: fast init done
[5.305730] random: systemd: uninitialized urandom read (16 bytes read)
[5.306079] random: systemd: uninitialized urandom read (16 bytes read)
[5.309089] random: systemd: uninitialized urandom read (16 bytes read)
[5.309237] random: systemd: uninitialized urandom read (16 bytes read)
[5.309399] random: systemd: uninitialized urandom read (16 bytes read)
[5.309598] random: systemd: uninitialized urandom read (16 bytes read)
[5.309751] random: systemd: uninitialized urandom read (16 bytes read)
[5.309900] random: systemd: uninitialized urandom read (16 bytes read)
[5.310030] random: systemd: uninitialized urandom read (16 bytes read)
[5.310093] random: systemd: uninitialized urandom read (16 bytes read)
[  313.172388] random: crng init done


Re: running arecord via ssh

2018-05-17 Thread Curt
On 2018-05-17, mick crane  wrote:
>> 
>> Is really arecord incompatible with ssh?
>> 
>> best regards,
>
> possibly it wants X for some reason and it is not on the ssh client.
> try, if windows, Xming, see if it works.

At any rate the answer to his question is no.

So it must be something else. 

As another poster has pointed out, we are in the dark to know what that
something else may be as the OP has not revealed crucial specifics à la
'cut and paste'.

> mick
>
>
>
>


-- 




Re: lightdm (testing): Long waiting time after login

2018-05-17 Thread Dino

On 16.05.2018 19:51 Dominic Knight wrote:

On Wed, 2018-05-16 at 14:53 +0200, Dino wrote:

Dino wrote:

This is a multi-part message in MIME format.
--D295C2A19D414A0F9C32AEE8
Content-Type: multipart/alternative;
   boundary="51A034E61483D85CC097E79C"


--51A034E61483D85CC097E79C
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

This time with attachment...

Am 16.05.2018 um 09:28 schrieb w...@hllmnn.de:

I just did a fresh install of testing with XFCE. After entering
the
login credentials the screen was black for 30-60 seconds before
the
desktop environment showed up. Assuming a bug in XFCE, I
performed
another fresh install with MATE, but a similar effect occured:
after
login the background image is shown for 30-60 seconds before
the
desktop is fully loaded.

A look into /var/log/lightdm/lightdm.log showed that the delay
happens
before VT is activated. The log file is attached.

Might this be a bug in lightdm or could a misconfiguragtion
from my
side cause this issue?

...

[+7.71s] DEBUG: Session pid=691: Running command
/etc/X11/Xsession default
[+7.71s] DEBUG: Creating shared data directory
/var/lib/lightdm/data/USERNAME
[+7.71s] DEBUG: Session pid=691: Logging to .xsession-errors
[+40.89s] DEBUG: Activating VT 7
[+40.89s] DEBUG: Activating login1 session 2
[+40.89s] DEBUG: Seat seat0 changes active session to
[+40.89s] DEBUG: Seat seat0 changes active session to 2
[+40.89s] DEBUG: Session 2 is already active

what does .xsession-errors say?

what type of device are you installing to?

my recent installs with netinst for testing and having MATE
comes up ok (within a few seconds), but things may have changed
in packages.

does a stable netinst give same results?


songbird

.xsession-errors contains one warning (file is attached), but I
don't
think that it causes the delay.

The device I'm installing to is an UDOO X86
(https://www.udoo.org/udoo-x86/). Basically, it's standard hardware
with
an Intel CPU. I already had an installation of testing a few months
ago
that didn't show this behaviour.

A stable netinst works just fine, the desktop is loaded almost
immediately. Hence, I assume a package changed recently is the
reason
for this.

Maybe;
systemd-analyze critical-chain
&
systemd-analyze blame
will give a clue as to what is taking its time?

Dom.
The output of systemd-analyze looks fine, I think. It really seems like 
the bug reported at 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897572 is causing the 
trouble.
  6.228s NetworkManager-wait-online.service
   736ms dev-sda1.device
   585ms networking.service
   470ms NetworkManager.service
   459ms systemd-logind.service
   459ms x2goserver.service
   368ms udisks2.service
   353ms systemd-timesyncd.service
   353ms upower.service
   280ms keyboard-setup.service
   271ms ModemManager.service
   254ms avahi-daemon.service
   189ms lm-sensors.service
   186ms systemd-udev-trigger.service
   171ms speech-dispatcher.service
   162ms wpa_supplicant.service
   146ms lightdm.service
   142ms systemd-journald.service
   129ms user@1000.service
   124ms systemd-tmpfiles-setup.service
   105ms pppd-dns.service
   104ms systemd-update-utmp.service
   101ms user@113.service
   100ms systemd-rfkill.service
93ms packagekit.service
91ms rsyslog.service
76ms systemd-udevd.service
71ms dev-disk-by\x2duuid-3d5845ff\x2d7dc2\x2d45e6\x2d9495\x2d2a95d09c804c.swap
69ms ssh.service
58ms polkit.service
42ms console-setup.service
37ms bluetooth.service
36ms systemd-tmpfiles-clean.service
34ms systemd-journal-flush.service
32ms systemd-sysusers.service
29ms dev-hugepages.mount
28ms hddtemp.service
27ms systemd-remount-fs.service
27ms dev-mqueue.mount
25ms systemd-tmpfiles-setup-dev.service
24ms rtkit-daemon.service
20ms systemd-sysctl.service
19ms sys-kernel-debug.mount
18ms systemd-modules-load.service
18ms systemd-update-utmp-runlevel.service
17ms kmod-static-nodes.service
15ms systemd-user-sessions.service
13ms systemd-random-seed.service


Re: running arecord via ssh

2018-05-17 Thread Pierre Frenkiel

On Thu, 17 May 2018, David Margerison wrote:


Details matter. Do not ever deliberately omit details.
unless you *know* they are not relevant.


  I thought that the details were not so useful, but here they are, if
  you think they may help to find the answer:

  1/ setting the line input of the sound card as input:

amixer -c 1 set Master,0 playback unmute 75%,75%
amixer -c 1 set Line,0 75%,75% mute cap
amixer -c 1 set Capture,0 75%,75% unmute cap

this works in all cases, i.e. I actually hear the sound  coming from
the line input

  2/ running arecord

arecord -d 10 -f cd -t wav tst.wav

this gives an empty file when run in a ssh window

NB: I also tried "xterm -e ssh mydesktop" instead of "ssh mydesktop"
with the same result (empty file)

best regards,
--
Pierre Frenkiel



Re: lightdm (testing): Long waiting time after login

2018-05-17 Thread Curt
On 2018-05-17, Dino  wrote:
>
> Yes, you're right! When I wiggle the mouse the wait ends sooner. Indeed, 
> if I don't move the mouse at all and don't press any key the screen just 
> stays blank (I waited approx. 5 minutes and it still was black).
>

https://wiki.archlinux.org/index.php/LightDM#LightDM_freezes_on_login_attempt

https://bbs.archlinux.org/viewtopic.php?id=179031*

Perhaps related to your issue.



Re: running arecord via ssh

2018-05-17 Thread tomas
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, May 17, 2018 at 11:56:51AM +0200, Pierre Frenkiel wrote:

[...]

>   2/ running arecord
> 
> arecord -d 10 -f cd -t wav tst.wav
> 
> this gives an empty file when run in a ssh window

Perhaps you might want to run arecord under strace (in both situations)
and compare results.

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlr9WnEACgkQBcgs9XrR2ka2wACeN3k4o/8DGgOgP7FQLAzviVBc
SekAn2FBfmX8Wf45IQlJz36SpmNkUjiO
=CfmH
-END PGP SIGNATURE-



Re: setting up a drive automount in systemd?

2018-05-17 Thread Darac Marjal

On Wed, May 16, 2018 at 09:24:27PM +0200, john doe wrote:

On 5/16/2018 9:04 PM, dep wrote:

On Wed, May 16, 2018 at 2:44 PM, john doe  wrote:


On 5/16/2018 6:25 PM, dep wrote: > greetings. > > i've tried my best to search the list archives for the answer to this 
and have not gotten the search function to deliver . . . anything. > > here's the issue. i have one of the new 
"gemini" devices, a psion-like smartphone-pda-computer that runs android and linux. i'm of course running linux. the 
linux available for it is a derivative of stretch arm64. it uses systemd, my first encounter with that not-universally-loved 
arrangement. > > the device has 64gb of onboard storage and a microSD slot, in which i've placed a 128gb microSD card 
formatted ext4. to reduce write wear on the device's internal memory, it's my hope to put /home or at least /[users] on the microSD 
card. this of course requires mounting it at boot. > > i've been much of a week searching and i cannot find any way to 
configure this to automount in systemd. i do not even know if under systemd it must be mounted to a mountpoint or if it's handled 
at the /dev level. so what was once a trivial configuration has become a more complicated one, with the possibility of bricking the 
device -- which i'd just as soon not do. > > can anyone here either give or point to clear and i hope simple instructions for 
configuring the card to mount at boot? alternately, is there systemd-friendly disk management software? the disk managers i'm 
familiar with do not seem to work with systemd. > > thanks in advance. > I might be missing something here but why not 
using the fstab file? -- John Doe


because there is no /etc/fstab.



1)  Fstab could be located somewhere else (find / -iname fstab -type f)
2)  What happens if you try to use /etc/fstab file?
3)  Anything in the log for a missing fstab file?
4)  Use a systemd service file to mount it at boot (Automatic mounting 
of additional volumes).


I'm on Stretch with systemd and a fstab file.


systemd doesn't actually use /etc/fstab for mounting drives. Instead, as 
with everything, it uses a unit file, specifically a *.mount file. "man 
systemd.mount" will give you all the gory details. Under the systemd 
regime, you CAN create a mount by creating a *.mount file in 
/etc/systemd/system.


However, before you go doing that, consider that systemd ALSO comes with 
a program called "systemd-fstab-generator". Contrary to its name, this 
generates unit files FROM an fstab (rather than generating an fstab). 
Therefore, following the Principle of Least Surprise, the current 
thinking is to continue to maintain your mountpoints in /etc/fstab and 
let systemd do the translation on the fly. 

In summary, then, while you CAN run systemd without /etc/fstab, that 
file is still recommnded as the expected configuration file for 
mountpoints.


--
For more information, please reread.


signature.asc
Description: PGP signature


Re: running arecord via ssh

2018-05-17 Thread Pierre Frenkiel

On Thu, 17 May 2018, to...@tuxteam.de wrote:


Perhaps you might want to run arecord under strace (in both situations)
and compare results.

  good idea. I'll try that, but I found a way to make arecord
  to work in all cases(God knows why): adding the "-D copy" option, i.e.

 arecord -d 10 -f cd -D copy -t wav tst.wav

this works after adding
   pcm.copy {
  type plug
  slave {
pcm hw
}
  route_policy copy
}

to .asoundrc.asoundconf

best regards,
--
Pierre Frenkiel



Re: UEFI/"BIOS" booting

2018-05-17 Thread Thomas Schmitt
Hi,

i wrote:
> > - Compromise is to set the boot flag on a dummy partition of type 0x00.
> >    This is barely UEFI-compliant because the specs say that a partition of
> >    type 0x00 shall be regarded as non-existent.

Pascal Hambourg wrote:
> - I had to use the old fdisk version from Wheezy because newer versions and
> other partition editors would not allow to set the boot flag on an empty
> partition entry.

You never know what kind of user-friendly abstraction a partition editor will
apply. So portable and future-safe is only the manipulation on byte level.

The layout of the MBR partition table can be learned from
  https://en.wikipedia.org/wiki/Master_boot_record#Sector_layout
  "Structure of a classical generic MBR" 
  https://en.wikipedia.org/wiki/Master_boot_record#Partition_table_entries

Partition entries are 16 bytes of size and number 1 begins at offset 446.
The boot/active flag sits in the first byte of the partition entry.
The value of this byte is either 0 or 128 (= 0x80 in hex). We want 128.
Further we need to write values for partition start and size.

  # Choose target disk or image file
  disk=/dev/sdX

  # Make a backup of your MBR by
  backup_path="$HOME"/mbr_backup_of_"$(basename "$disk")"
  dd if="$disk" bs=512 count=1 conv=notrunc of="$backup_path"

  # Restore the backup to $disk would be done like this:
  #   dd if="$backup_path" bs=512 count=1 conv=notrunc of="$disk"
  # If $disk is the system disk: Have a rescue system ready which can
  # access the backup file and the system disk.

  # Choose partition and compute start of its entry
  partno=2
  offset=$(expr 430 + "$partno" '*' 16)

  # First set the partition entry to all zeros. So we can just hop over
  # those bytes which shall stay 0. This spares us the plight to handle
  # 0-bytes by shell commands.
  dd if=/dev/zero bs=1 count=16 conv=notrunc seek="$offset" of="$disk"

  # The boot/active flag
  # (The gesture $'\xHH' is described in man bash section QUOTING.)
  echo -n $'\x80' | dd bs=1 count=1 conv=notrunc seek="$offset" of="$disk"

  # Start C/H/S = 0/0/1
  offset=$(expr "$offset" + 2)
  echo -n $'\x01' | dd bs=1 count=1 conv=notrunc seek="$offset" of="$disk"

  # End C/H/S = 0/0/1
  offset=$(expr "$offset" + 4)
  echo -n $'\x01' | dd bs=1 count=1 conv=notrunc seek="$offset" of="$disk"

  # Sector count = 1 (start LBA is 0)
  offset=$(expr "$offset" + 6)
  echo -n $'\x01' | dd bs=1 count=1 conv=notrunc seek="$offset" of="$disk"

The task would also be a good execercise for Programmer's First C Program.


Have a nice day :)

Thomas



Re: "pre-treating" documents from certain remote URLs before a web browser renders them

2018-05-17 Thread Celejar
On Thu, 17 May 2018 08:49:04 +0200
 wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Wed, May 16, 2018 at 07:35:51PM -0700, Kushal Kumaran wrote:
> 
> [...]
> 
> > You should note that HTTP-proxy based systems will not be able to do any
> > inspection or modification of traffic for sites using HTTPS.
> 
> This is true... and then it's not :-)
> 
> If your proxy terminates the HTTPS connection, effectively doing a
> "man-in-the-middle" (but controlled by you), it can: most probably
> you'd have to fool your browser by offering it a HTTPS connection
> from the proxy, and by installing a trusted root certificate you
> create yourself. Basically what the proxy in your $CORPORATION does
> all of the time.
> 
> I don't know whether privoxy or squid can do that (I'd love to know,
> mind you, but days are so short).

Privoxy apparently has no native support for this, but people have
apparenly constructed working solutions using things like stunnel and
ProxHTTPSProxy:

https://www.stunnel.org/pipermail/stunnel-users/2006-April/001083.html
https://sourceforge.net/p/ijbswa/support-requests/1512/
https://sourceforge.net/p/ijbswa/support-requests/1667/
https://sourceforge.net/p/ijbswa/support-requests/1654/
https://news.ycombinator.com/item?id=8822974


Celejar



Re: "pre-treating" documents from certain remote URLs before a web browser renders them

2018-05-17 Thread tomas
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, May 17, 2018 at 07:52:55AM -0400, Celejar wrote:
> On Thu, 17 May 2018 08:49:04 +0200
>  wrote:

[... proxy as SSL endpoint...]

> > I don't know whether privoxy or squid can do that (I'd love to know,
> > mind you, but days are so short).
> 
> Privoxy apparently has no native support for this, but people have
> apparenly constructed working solutions using things like stunnel and
> ProxHTTPSProxy:
> 
> https://www.stunnel.org/pipermail/stunnel-users/2006-April/001083.html
> https://sourceforge.net/p/ijbswa/support-requests/1512/
> https://sourceforge.net/p/ijbswa/support-requests/1667/
> https://sourceforge.net/p/ijbswa/support-requests/1654/
> https://news.ycombinator.com/item?id=8822974

Thanks :)

Cheers
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlr9blQACgkQBcgs9XrR2kb6twCfeqhf31EAMdjdf/7hEtlWAHH7
uDoAn2iZeKbQ1jOekXvVok7VmuTem+jk
=bxPE
-END PGP SIGNATURE-



pppd: how to die on connection lost

2018-05-17 Thread Morel Bérenger
Hello.

I am trying to make the pppd process to die if connection failed or is
lost, so that I could restart the connection with a different script (I
could tweak the chat script, but I'm still new to modem stuff and from
the doc I can hardily find how to only specify the PIN code "once per
hardware uptime" if you get what I mean).

I tried to read documentation from various sources, including debian's
manpages, but failed to do that, so now I'm reading the code to see if
it is possible to at least die if the chat script failed.

While reading the code ("apt-get sources ppp" gave me ppp-2-4-7, I'm
on stretch), I've noticed a variable that might be used without being
initialized. In fact, grep can not find any place where it's value is
set:

ppp-2.4.7% grep -r callback_script -n
debian/ppp.symbols:54: callback_script@Base 2.4.7-1+2~
pppd/tty.c:132:char *callback_script;   /* script for
doing callback */
pppd/tty.c:562: connector = doing_callback?
callback_script: connect_script;

To me, it seems quite strange, and may be source of problems, but I
guess there is some explanations?

Best regards.

-- 
SGA Automation
27 Rue Jean-Philippe Rameau
Pôle Delta
76000 Rouen
Tel : 02 32 10 38 53
Fax : 02 32 10 11 30
www.sga-automation.com
Email : berenger.mo...@sga-automation.com


pgpLk1249t5IO.pgp
Description: Signature digitale OpenPGP


Re: "pre-treating" documents from certain remote URLs before a web browser renders them

2018-05-17 Thread Reco
Hi.

On Thu, May 17, 2018 at 08:49:04AM +0200, to...@tuxteam.de wrote:
> On Wed, May 16, 2018 at 07:35:51PM -0700, Kushal Kumaran wrote:
> 
> [...]
> 
> > You should note that HTTP-proxy based systems will not be able to do any
> > inspection or modification of traffic for sites using HTTPS.
> 
> This is true... and then it's not :-)
> 
> If your proxy terminates the HTTPS connection, effectively doing a
> "man-in-the-middle" (but controlled by you), it can: most probably
> you'd have to fool your browser by offering it a HTTPS connection
> from the proxy, and by installing a trusted root certificate you
> create yourself. Basically what the proxy in your $CORPORATION does
> all of the time.
> 
> I don't know whether privoxy or squid can do that (I'd love to know,
> mind you, but days are so short).

Squid can do it. It was called SSL Bump in old (pre 3.4) Squid, now they
renamed it to SSL Peek and Splice - [1].

Reco

https://wiki.squid-cache.org/Features/SslPeekAndSplice



Re: "pre-treating" documents from certain remote URLs before a web browser renders them

2018-05-17 Thread tomas
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, May 17, 2018 at 03:40:24PM +0300, Reco wrote:

[...]

> Squid can do it. It was called SSL Bump in old (pre 3.4) Squid, now they
> renamed it to SSL Peek and Splice - [1].

Thanks!

- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlr9lVUACgkQBcgs9XrR2kZKQwCfeq9ciQccW5icyx6mjlCJtqyV
PfcAn212kZ1EV3HtgetETHgd/NFsGpE6
=IRRz
-END PGP SIGNATURE-



Re: Re: Where is templato to create package?

2018-05-17 Thread Cindy-Sue Causey
On 5/17/18, ox16  wrote:
> Dnia 14 maja 2018 20:10 Joseph Herlant 
> napisał(a):  Hi guys,   mentors.debian.net mentors.debian.net  is a good
> placed to start.   Ok, can You show me source code of package?  I'm
> searching but not found.  I ask about file and formats.   I must create a
> package first. This is only one file.


On 5/17/18, ox16  wrote:
> Dnia 14 maja 2018 20:10 Joseph Herlant 
> napisał(a):  Hi guys,   mentors.debian.net mentors.debian.net  is a good
> placed to start.   Ok, can You show me source code of package?  I'm
> searching but not found.  I ask about file and formats.   I must create a
> package first. This is only one file.


The maint-guide offline resource that we can install locally starts by
showing what is necessary. This is the same guide in an online form:

https://www.debian.org/doc/manuals/maint-guide/first.en.html

I just checked and that guide is additionally part of Joseph's
recommendation. Joseph's also suggests the following which may say
something in a different that is more understandable:

https://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial

Additionally... If this was me as a new developer trying to find out
how to present a font such that it displays in Debian and thus likely
other operating systems, I would use my package manager to find a
similar font. I'd then inspect that font's package contents to see how
its author *successfully* presented their [product] such that it was
*successfully* accepted into Debian's repository.

BUT... I would also make sure that the previously existing font
package doesn't have any outstanding quality issues that are not
immediately apparent. I wouldn't want to unintentionally duplicate
those quality issues into my own brand new package. That's where the
Debian Package Tracker comes into play as a handy tool:

https://tracker.debian.org/

If you find a fonts package that would be easy to use as a template,
run it through the Tracker first then correct that package's issues
before proceeding forward with your own. If you do use another package
as a template for your own, don't forget to credit if/as
appropriate/needed/requested by that package's developer. :)

Good luck!

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with duct tape *



Re: pppd: how to die on connection lost

2018-05-17 Thread David Wright
On Thu 17 May 2018 at 09:14:48 (+0200), Morel Bérenger wrote:
> Hello.
> 
> I am trying to make the pppd process to die if connection failed or is
> lost, so that I could restart the connection with a different script (I
> could tweak the chat script, but I'm still new to modem stuff and from
> the doc I can hardily find how to only specify the PIN code "once per
> hardware uptime" if you get what I mean).
> 
> I tried to read documentation from various sources, including debian's
> manpages, but failed to do that, so now I'm reading the code to see if
> it is possible to at least die if the chat script failed.
> 
> While reading the code ("apt-get sources ppp" gave me ppp-2-4-7, I'm
> on stretch), I've noticed a variable that might be used without being
> initialized. In fact, grep can not find any place where it's value is
> set:
> 
> ppp-2.4.7% grep -r callback_script -n
> debian/ppp.symbols:54: callback_script@Base 2.4.7-1+2~
> pppd/tty.c:132:char *callback_script; /* script for
> doing callback */
> pppd/tty.c:562:   connector = doing_callback?
> callback_script: connect_script;
> 
> To me, it seems quite strange, and may be source of problems, but I
> guess there is some explanations?

I used to use ppp with callback (if I understand correctly what you're
doing) up until about 15 years ago. But ppp didn't dial or pick up the
calls: that was done by the mgetty package that managed the modem.

I would always be sitting in front on the PC that dialled the original
call and received the callback, so I was always aware if the connection
dropped for any reason.

But if I wanted to automate a reconnection after the line dropped,
I would probably be watching mgetty's logs and syslog with tail -F.
For example, at the calling-back end, mgetty dies and is respawned
when the call drops. I don't remember what's logged at my end because
I could see the modem lights and hear its clicks and characteristic beeps.

During the connection, pinging the other end is useful just to make
sure that data is passing.

Cheers,
David.



filter network traffic of KVM guests.

2018-05-17 Thread Chris
All,

I'd like to filter network traffic of KVM guests.

case A:
- no MAC / IP Spoofing
- isolate guest, connections to the gateway only
- no connection to the KVM host
- no NAT
- maybe contradictory: same subnet as KVM host

case B:
- no MAC / IP Spoofing
- isolate guest, connections to the gateway only
- no connection to the KVM host
- no NAT
- some guests should share a "private VLAN"

What's the easiest way to separate KVM guests' traffic on the host?

I read it's deprecated to use iptables on a linux bridge. [1]

I don't like the libvirt (NAT) iptables rules. The default libvirt
network connections aren't secure the way they are pre-configured.
A good summary is in [2] (German only).

Is Open vSwitch a viable solution? Can OVS ACLs (or firewall) be used 
instead of iptables? I'm a bit surprised, that I couldn't find more 
about it on this list.


Chris



[1] http://lists.gnu.org/archive/html/qemu-devel/2009-07/msg01592.html
[2]
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Studien/Sicherheitsanalyse_KVM/Sicherheitsanalyse_KVM.pdf?__blob=publicationFile&v=3

-- 
Papst Franziskus ruft zum Kampf gegen Fake News auf. Wir finden, der
Mann, der sich als Stellvertreter Christi ausgibt, von dem er
behauptet, dessen Mutter sei zeitlebens Jungfrau gewesen, er hätte über
Wasser gehen und selbiges in Wein verwandeln können, hat vollkommen
recht.



Re: Auto-assembled SW RAID in rescue mode

2018-05-17 Thread Pascal Hambourg

Sorry for the late reply, I did not see your post until now.

Le 14/05/2018 à 12:37, Niclas Arndt a écrit :


mdadm.conf says metadata=1.2.


So there is no risk that that the whole disk may be wrongly detected as 
a RAID member instead of the last partition.



root@file2:~# blkid /dev/md2*
/dev/md2: PTUUID="41440b8b-c8dc-489c-9f03-e85d8d309302" PTTYPE="gpt"
/dev/md2p1: UUID="1c3642c6-c51c-4bd1-b952-5a77665e3d18" TYPE="ext4" 
PARTUUID="eb6ee4f4-95ec-449e-a9e8-1bca9a837afb"
root@file2:~#
root@file2:~# file -sk /dev/md2
/dev/md2: DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,1),
end-CHS (0x3ff,254,63), startsector 1, 4294967295 sectors, extended
partition table (last) DOS/MBR boot sector GPT partition table, version
1.0, GUID: 41440b8b-c8dc-489c-9f03-e85d8d309302, disk size: 38676285440
sectors of 512 bytes\012- data
root@file2:~#
root@file2:~# wipefs /dev/md2
offset   type

0x200gpt   [partition table]


There is no evidence that /dev/md2 contains a filesystem. So trying to 
mount it should have failed.




Re: filter network traffic of KVM guests.

2018-05-17 Thread Reco
Hi.

On Thu, May 17, 2018 at 08:11:06PM +0200, Chris wrote:
> All,
> 
> I'd like to filter network traffic of KVM guests.
> 
> case A:
> - no MAC / IP Spoofing
> - isolate guest, connections to the gateway only
> - no connection to the KVM host
> - no NAT
> - maybe contradictory: same subnet as KVM host

Either ebtables (for a conventional brigde) or macvtap in private mode
will do it. Openvswitch will work too, but it's nowhere near in
simplicity compared to macvtap.


> case B:
> - no MAC / IP Spoofing
> - isolate guest, connections to the gateway only
> - no connection to the KVM host
> - no NAT
> - some guests should share a "private VLAN"

Ditto, but combine private macvtap with external reflector switch.

> What's the easiest way to separate KVM guests' traffic on the host?
> 
> I read it's deprecated to use iptables on a linux bridge. [1]

Yup, you should not. Besides, iptables is for IP-based protocols anyway.
There are ebtables if you really need to deal with the bridges.


> I don't like the libvirt (NAT) iptables rules. The default libvirt
> network connections aren't secure the way they are pre-configured.
> A good summary is in [2] (German only).

It's designed with desktop vitualization in mind, so it's no wonder it's
unsuitable for anything even remotely looking like a server :).


> Is Open vSwitch a viable solution? Can OVS ACLs (or firewall) be used 
> instead of iptables?

You got it wrong. If you're implementing openvswtich, you *have* to
utilize its flows instead of iptables. Openvswitch bypasses netfilter by
design.

Reco



Re: USB Install Fails, Complains about CD-ROM

2018-05-17 Thread Mike Kupfer
Thomas Schmitt wrote:

> Mike Kupfer wrote:
> > I used sha256sum instead of sha512sum, but I otherwise followed
> > the above instructions.  The checksum from the dd pipeline does not
> > match the checksum of the original .iso file.
> 
> That's not good.
> Especially we do not have to show up at grub-devel as long as the test
> USB stick might have problems as storage device.
> 
> 
> >   dd if=/dev/sdb count=950976 bs=2048 | sha256sum
> > gives me the same result as
> >   sha256sum /dev/sdb1
> 
> That's normal with Debian ISOs for "i386" and "amd64". The first partition
> marks the whole ISO.

That is true for the 9.4 netinst ISO, but there seems to be something
odd going on with the live image ISOs.

  alto$ sudo dd if=debian-live-9.4.0-amd64-xfce.iso of=/dev/sdb bs=32K
  [sudo] password for kupfer: 
  59554+0 records in
  59554+0 records out
  1951465472 bytes (2.0 GB, 1.8 GiB) copied, 455.702 s, 4.3 MB/s
  alto$ sudo isosize -x /dev/sdb
  sector count: 952848, sector size: 2048

But 952848 * 2048 = 1951432704, not 1951465472.

If I calculate the sector count from the size of the .iso file

  1951465472 / 2048 = 952864

and use that with dd piped to sha256sum, I do get the correct checksum:

dd if=/dev/sdb count=952864 bs=2048 | sha256sum
5d6f990bdd618902f9c0ce4b090d6547a77d89c3bab87136e6adf9a9378f4f39 -

That matches the value for the .iso, and it matches the value in
SHA256SUMS.

I saw this when testing multiple sticks, including the Verbatim stick
mentioned below, so I don't think this is a hardware glitch.  And I
observed something similar with the 9.2 Xfce live image ISO.

> > I just tried 9.4, using a different USB stick.  It fails in the same way

After running several tests, with 4 different sticks, 2 different ISOs
(the 9.4 netinst ISO and the 9.4 Xfce live image ISO), and 2 different
computers (the Latitude and my desktop), I believe the problem is, in
fact, the USB stick.  And not just the first one that I had problems
with.  It looks like there's something about that entire make/model
(MOSDART 8GB).  3 of the 4 sticks that I tested were MOSDART sticks, and
the 4th was a Verbatim stick.  I had problems with all 3 MOSDART sticks,
with both ISOs and both computers.  I had no problems with the Verbatim
stick with either ISO or computer, and that includes multiple tests
without any sort of "resting period" (with the power turned off).

Thomas, thanks again for all your help on this.  I'll have to be more
careful the next time I'm buying storage.

mike



Re: filter network traffic of KVM guests.

2018-05-17 Thread Richard Hector
On 18/05/18 08:11, Reco wrote:
>> I read it's deprecated to use iptables on a linux bridge. [1]
> Yup, you should not.
Interesting, I wasn't aware of that.

Does that just apply to running iptables on the host?

Or should I also not run it in the vm (eg on a rented VPS, where I
assume the net device is backed by a bridge)?

Presumably if it causes a security hole, I shouldn't be _able_ to run it
in the VM?

Richard



signature.asc
Description: OpenPGP digital signature


making more room in root partition for distribution upgrade

2018-05-17 Thread Mark Copper
There was a day when a 10 gb partition seemed like plenty of space to leave
for the system but now it's not. An upgrade to Stretch appears to need more.

~# fdisk -l

Disk /dev/sda: 149.1 GiB, 160041885696 bytes, 312581808 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0007c9ed

Device BootStart   End   Sectors   Size Id Type
/dev/sda1  *2048  19531775  19529728   9.3G 83 Linux
/dev/sda2   19533822 312580095 293046274 139.8G  5 Extended
/dev/sda5   19533824  27578367   8044544   3.9G 82 Linux swap / Solaris
/dev/sda6   27580416 312580095 284999680 135.9G 83 Linux

$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
#
proc/proc   procdefaults0   0
# / was on /dev/sda1 during installation
UUID=f2959403-fb9c-4e56-adbf-e5b7c1f63dd8 /   ext3
errors=remount-ro 0   1
# /home was on /dev/sda6 during installation
UUID=274b606c-c556-47cb-8db3-2733b7adac3f /home   ext3
defaults0   2
# swap was on /dev/sda5 during installation
UUID=5642269c-ada4-4466-a516-4a2360ee0ec1 noneswap
sw  0   0


This must be a FAQ. But there appear to be two ways forward.

1. Back-up /home, enlarge / partition, copy back-up back to new, smaller
/home partition (because /home will then start on a different cylinder so
data will be lost).

or

2. Carve out a new partition for /usr at end of disk which will free up
over 6 gb.

What have other people done?

Thanks.


Re: lightdm (testing): Long waiting time after login

2018-05-17 Thread Ben Caradoc-Davies

On 17/05/18 21:02, Dino wrote:
Yes, you're right! When I wiggle the mouse the wait ends sooner. Indeed, 
if I don't move the mouse at all and don't press any key the screen just 
stays blank (I waited approx. 5 minutes and it still was black).
I attached the output of dmesg | grep "random". As you can see, "crng 
init done" appears after the 5 minutes I waited.


Yes, this seems to confirm my suspicion that something is blocking by 
calling getrandom without GRND_NONBLOCK.


Since there is no "splash" in my kernel command line in grub, I added 
"noplymouth" to it, but that didn't help. Maybe it's another package 
that calls getrandom without GRND_NONBLOCK. Let me know if I can support 
the investigation somehow.
The situation you describe does not implicate plymouth, because the 
pause occurs after you enter your credentials. This is a tricky one, 
because it could be lightdm, or systemd which is a known offender, xorg, 
or anything else in your session. This is a tricky problem to diagnose 
because, as soon as you start typing, your login will complete. I 
suggest reporting this against lightdm to get maintainer advice. The 
Debian Xfce and lightdm maintainer has commented on #897572 and is aware 
of the getrandom issue, but I could not find any lightdm issue for it.


Which iso image did you use to install testing?

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand



Re: GPG error when trying to update Lenny

2018-05-17 Thread Mark Fletcher
On Wed, May 16, 2018 at 03:20:09PM +, Marie-Madeleine Gullibert wrote:
> Hello to all, 
> 
> I'm relatively new to Debian. I'm helping out a small organization that has a 
> library server installed on Debian to update their system. They run currently 
> on Debian lenny so I'm first trying to upgrade the Debian system, but I keep 
> running into a GPG error when I try to first update. I've tried many things 
> but none have worked so far, and would gladly welcome any suggestions. I do 
> have debian-archive-keyring installed (and up to date) and I've tried 
> retrieving my expired keys from a two different keyservers to no avail. 
> 
> Here's what happens (I'm running as root): 
> 
> localhost:~# apt-get update
> Get:1 http://archive.debian.org lenny Release.gpg [1034B]
> Ign http://archive.debian.org lenny/main Translation-en_US
> Get:2 http://archive.debian.org lenny/updates Release.gpg [836B]
> Ign http://archive.debian.org lenny/updates/main Translation-en_US
> Ign http://archive.debian.org lenny/updates/contrib Translation-en_US
> Get:3 http://archive.debian.org lenny/volatile Release.gpg [481B]
> Ign http://archive.debian.org lenny/volatile/main Translation-en_US
> Hit http://archive.debian.org lenny Release
> Hit http://archive.debian.org lenny/updates Release
> Hit http://archive.debian.org lenny/volatile Release
> Get:4 http://archive.debian.org lenny Release [99.6kB]
> Get:5 http://archive.debian.org lenny/updates Release [92.4kB]
> Ign http://archive.debian.org lenny Release
> Get:6 http://archive.debian.org lenny/volatile Release [40.7kB]
> Ign http://archive.debian.org lenny/updates Release
> Ign http://archive.debian.org lenny/volatile Release
> Ign http://archive.debian.org lenny/main Packages/DiffIndex
> Ign http://archive.debian.org lenny/main Sources/DiffIndex
> Ign http://archive.debian.org lenny/updates/main Packages/DiffIndex
> Ign http://archive.debian.org lenny/updates/contrib Packages/DiffIndex
> Ign http://archive.debian.org lenny/updates/main Sources/DiffIndex
> Ign http://archive.debian.org lenny/updates/contrib Sources/DiffIndex
> Ign http://archive.debian.org lenny/volatile/main Packages/DiffIndex
> Ign http://archive.debian.org lenny/volatile/main Sources/DiffIndex
> Hit http://archive.debian.org lenny/main Packages
> Hit http://archive.debian.org lenny/main Sources
> Hit http://archive.debian.org lenny/updates/main Packages
> Hit http://archive.debian.org lenny/updates/contrib Packages
> Hit http://archive.debian.org lenny/updates/main Sources
> Hit http://archive.debian.org lenny/updates/contrib Sources
> Hit http://archive.debian.org lenny/volatile/main Packages
> Hit http://archive.debian.org lenny/volatile/main Sources
> Fetched 235kB in 0s (301kB/s)
> Reading package lists... Done
> W: GPG error: http://archive.debian.org lenny Release: The following 
> signatures were invalid: KEYEXPIRED 1520281423 KEYEXPIRED 1337087218
> W: GPG error: http://archive.debian.org lenny/updates Release: The following 
> signatures were invalid: KEYEXPIRED 1356982504
> W: GPG error: http://archive.debian.org lenny/volatile Release: The following 
> signatures were invalid: KEYEXPIRED 1358963195
> W: You may want to run apt-get update to correct these problems
> 

Since you want to upgrade the installation to a later version, my 
suggestion is don't bother first trying to update Lenny. Just update 
your sources.list to the next release (was that Jessie? I don't even 
recall) and then update as usual.

Some releases had recommendations to use aptitude / not use aptitude, as 
opposed to apt-get, to do the update, I don't recall now if releases 
after Lenny did, but hopefully this comment will trigger someone else 
who does remember to chime in. Google may still be able to find old 
copies of the upgrade guides that are published with each new Debian 
release.

The only other piece of advice I have is don't try to go straight to 
stretch or buster from lenny -- instead upgrade one major release at a 
time, as that path is better trodden and more likely to work, and any 
issues you encounter are more likely to have been well-discussed in 
places Google can find (including the archives of this list).

Mark



Re: setting up a drive automount in systemd?

2018-05-17 Thread Mark Fletcher
On Thu, May 17, 2018 at 11:36:01AM +0100, Darac Marjal wrote:

> However, before you go doing that, consider that systemd ALSO comes with a
> program called "systemd-fstab-generator". Contrary to its name, this
> generates unit files FROM an fstab (rather than generating an fstab).
> Therefore, following the Principle of Least Surprise, the current thinking
> is to continue to maintain your mountpoints in /etc/fstab and let systemd do
> the translation on the fly.
> 
> In summary, then, while you CAN run systemd without /etc/fstab, that file is
> still recommnded as the expected configuration file for mountpoints.
> 

That has the ring of good advice. Especially since there could easily be 
other programs on your system that expect to find information about the 
mountpoints on the system by looking in fstab -- it's a file on the 
system, it's a long-standing standard, people are allowed to look at it 
and it's not unreasonable to imagine some piece of software will.

Mark



NetworkManager.service: Start request repeated too quickly

2018-05-17 Thread Dan Norton
In trying to get DNS working on a minimal install of Debian 9.4, by
copying things from a working system, I run into this:

# systemctl status NetworkManager
● NetworkManager.service - Network Manager
   Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled;
vendor preset: enabled) Active: failed (Result: exit-code) since Thu
2018-05-17 18:05:21 EDT; 1min 19s ago Docs: man:NetworkManager(8)
  Process: 571 ExecStart=/usr/sbin/NetworkManager --no-daemon
(code=exited, status=127) Main PID: 571 (code=exited, status=127)

May 17 18:05:20 debm systemd[1]: NetworkManager.service: Unit entered
failed state. May 17 18:05:20 debm systemd[1]: NetworkManager.service:
Failed with result 'exit-code'. May 17 18:05:21 debm systemd[1]:
NetworkManager.service: Service hold-off time over, scheduling restart.
May 17 18:05:21 debm systemd[1]: Stopped Network Manager. May 17
18:05:21 debm systemd[1]: NetworkManager.service: Start request
repeated too quickly. May 17 18:05:21 debm systemd[1]: Failed to start
Network Manager. May 17 18:05:21 debm systemd[1]:
NetworkManager.service: Unit entered failed state. May 17 18:05:21 debm
systemd[1]: NetworkManager.service: Failed with result 'exit-code'.

Sorry for the line folding. I left out how I got to this point, hoping
the cause would be obvious. Just ask if you want the lead-in to the
above. Thanks.

 - Dan



Re: making more room in root partition for distribution upgrade

2018-05-17 Thread Mark Copper
On Thu, May 17, 2018 at 6:32 PM, bw  wrote:

>
>
> On Thu, 17 May 2018, Mark Copper wrote:
>
> > There was a day when a 10 gb partition seemed like plenty of space to
> leave
> > for the system but now it's not. An upgrade to Stretch appears to need
> more.
> >
> > ~# fdisk -l
> >
> > Disk /dev/sda: 149.1 GiB, 160041885696 bytes, 312581808 sectors
> > Units: sectors of 1 * 512 = 512 bytes
> > Sector size (logical/physical): 512 bytes / 512 bytes
> > I/O size (minimum/optimal): 512 bytes / 512 bytes
> > Disklabel type: dos
> > Disk identifier: 0x0007c9ed
> >
> > Device BootStart   End   Sectors   Size Id Type
> > /dev/sda1  *2048  19531775  19529728   9.3G 83 Linux
> > /dev/sda2   19533822 312580095 293046274 139.8G  5 Extended
> > /dev/sda5   19533824  27578367   8044544   3.9G 82 Linux swap /
> Solaris
> > /dev/sda6   27580416 312580095 284999680 135.9G 83 Linux
> >
> > $ cat /etc/fstab
> > # /etc/fstab: static file system information.
> > #
> > # Use 'blkid' to print the universally unique identifier for a
> > # device; this may be used with UUID= as a more robust way to name
> devices
> > # that works even if disks are added and removed. See fstab(5).
> > #
> > #
> > proc/proc   procdefaults0   0
> > # / was on /dev/sda1 during installation
> > UUID=f2959403-fb9c-4e56-adbf-e5b7c1f63dd8 /   ext3
> > errors=remount-ro 0   1
> > # /home was on /dev/sda6 during installation
> > UUID=274b606c-c556-47cb-8db3-2733b7adac3f /home   ext3
> > defaults0   2
> > # swap was on /dev/sda5 during installation
> > UUID=5642269c-ada4-4466-a516-4a2360ee0ec1 noneswap
> > sw  0   0
> >
> >
> > This must be a FAQ. But there appear to be two ways forward.
> >
> > 1. Back-up /home, enlarge / partition, copy back-up back to new, smaller
> > /home partition (because /home will then start on a different cylinder so
> > data will be lost).
> >
> > or
> >
> > 2. Carve out a new partition for /usr at end of disk which will free up
> > over 6 gb.
> >
> > What have other people done?
> >
> > Thanks.
> >
>
> release notes on upgrading have some info about disk space.  It's maybe
> /var/cache/apt/archives taking up all your space?  I use 30 gb partitions
> usually and they very rarely get over 8-10 gigs.
>
> https://www.debian.org/releases/stable/amd64/release-
> notes/ch-upgrading.en.html#sufficient-space
>
> good luck!
>
>
I think I'm good there:

$ du -h /var
...
598M/var

but

$ du -h /usr
...
4.2G/usr/share
6.5G/usr

Point well taken about removing packages though.  Thanks


Re: making more room in root partition for distribution upgrade

2018-05-17 Thread Abdullah Ramazanoğlu
On Thu, 17 May 2018 18:06:46 -0500 Mark Copper said:

[ ---8<--- ]

> This must be a FAQ. But there appear to be two ways forward.
> 
> 1. Back-up /home, enlarge / partition, copy back-up back to new, smaller
> /home partition (because /home will then start on a different cylinder so
> data will be lost).
> 
> or
> 
> 2. Carve out a new partition for /usr at end of disk which will free up
> over 6 gb.

I had the same problem a while ago and enlarged my root partition from 10G to
40G. I guess it was a bit overkill, as my root partition is 8,5G now. So I
think 20 to 30 G depending on usage specifics should be fine.

I would recommend against (2) the reason being the more partitioned your disk
layout, the less efficient use of disk space (the more pooled the more
efficient use of space).

So, your actual disk layout is quite sensible IMO, and I would have stuck (1).
But then, once /home is backed up, there is no more need to "enlarge" the root
partition (as in resize2fs, if you meant that). I would have simply
re-partitioned the disk with the same layout as it is now (except different
partition sizes), do a fresh install, and then restore /home to its new
partition.

Regards
-- 
Abdullah Ramazanoğlu




Re: making more room in root partition for distribution upgrade

2018-05-17 Thread Andy Smith
Hi,

On Thu, May 17, 2018 at 06:06:46PM -0500, Mark Copper wrote:

[sda1 root partition got too small; extended partition on sda2 fills
remainder of disk]

> This must be a FAQ. But there appear to be two ways forward.
> 
> 1. Back-up /home, enlarge / partition, copy back-up back to new, smaller
> /home partition (because /home will then start on a different cylinder so
> data will be lost).
> 
> or
> 
> 2. Carve out a new partition for /usr at end of disk which will free up
> over 6 gb.
> 
> What have other people done?

If using multiple partitions per disk, consider using LVM in future
as otherwise this sort of thing nearly always becomes a chore.

Personally in your situation I'd probably back up /home and then
turn /home's device (/dev/sda6) into an LVM PV, then create LVs for
/home, /var and whatever else takes up significant space before
copying the /home data back in.

My reasoning for this is that as you do all of this work as root,
everything in /home is basically just data that is not required for
managing the system. Therefore the procedure is simpler and less
error-prone, in my opinion. It avoids messing about with the root
filesystem, and any kind of partition resizing.

When using LVM I don't tend to split up / and /usr. It is perfectly
possible to have / in LVM; modern grub will cope. But I tend to find
that after one has put all of the larger subdirectories into their
own LV, the combined space usage of /-and-/usr is fairly small and
mostly static. So for simplicity's sake I just rather pick a
reasonable size for / and keep it as a real partition with /usr
inside it.

I don't generally see the point of putting swap into LVM either,
again because the size of it rarely changes. Should you find you do
require more swap it can always be added later as devices or
swapfile.

As you can see I greatly value simplicity, which for me is a
hard-won lesson in the sysadmin trenches. Other people like a more
exciting life, so each to their own. :)

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting



Re: NetworkManager.service: Start request repeated too quickly

2018-05-17 Thread Dan Norton
On Thu, 17 May 2018 19:34:30 -0400
Dan Norton  wrote:

> In trying to get DNS working on a minimal install of Debian 9.4, by
> copying things from a working system, I run into this:
> 
> # systemctl status NetworkManager
> ● NetworkManager.service - Network Manager
>Loaded: loaded (/lib/systemd/system/NetworkManager.service;
> enabled; vendor preset: enabled) Active: failed (Result: exit-code)
> since Thu 2018-05-17 18:05:21 EDT; 1min 19s ago Docs:
> man:NetworkManager(8) Process: 571 ExecStart=/usr/sbin/NetworkManager
> --no-daemon (code=exited, status=127) Main PID: 571 (code=exited,
> status=127)
> 
> May 17 18:05:20 debm systemd[1]: NetworkManager.service: Unit entered
> failed state. May 17 18:05:20 debm systemd[1]: NetworkManager.service:
> Failed with result 'exit-code'. May 17 18:05:21 debm systemd[1]:
> NetworkManager.service: Service hold-off time over, scheduling
> restart. May 17 18:05:21 debm systemd[1]: Stopped Network Manager.
> May 17 18:05:21 debm systemd[1]: NetworkManager.service: Start request
> repeated too quickly. May 17 18:05:21 debm systemd[1]: Failed to start
> Network Manager. May 17 18:05:21 debm systemd[1]:
> NetworkManager.service: Unit entered failed state. May 17 18:05:21
> debm systemd[1]: NetworkManager.service: Failed with result
> 'exit-code'.
> 

More searching in the output of "journalctl -xe" turns up:

debm NetworkManager[583]: /usr/sbin/NetworkManager: error while loading
shared libraries: libjansson.so.4: cannot open shared object file: No
such file or directory

In another (non-minimal) system with a working DNS:

root@debU:~# apt search libjansson
[snip]
libjansson4/stable,now 2.9-1 amd64 [installed,automatic] 
C library for encoding, decoding and manipulating JSON data

Says it's installed but where? Running "whereis" turns up nothing.



Re: NetworkManager.service: Start request repeated too quickly

2018-05-17 Thread Andy Smith
Hello,

On Thu, May 17, 2018 at 09:31:26PM -0400, Dan Norton wrote:
> In another (non-minimal) system with a working DNS:
> 
> root@debU:~# apt search libjansson
> [snip]
> libjansson4/stable,now 2.9-1 amd64 [installed,automatic] 
> C library for encoding, decoding and manipulating JSON data
> 
> Says it's installed but where? Running "whereis" turns up nothing.

$ apt-file search libjansson.so.4
libjansson4: /usr/lib/x86_64-linux-gnu/libjansson.so.4
libjansson4: /usr/lib/x86_64-linux-gnu/libjansson.so.4.9.0

Also, for installed packages, "dpkg -L libjansson4".

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting



Re: NetworkManager.service: Start request repeated too quickly

2018-05-17 Thread Dan Norton
On Fri, 18 May 2018 01:41:35 +
Andy Smith  wrote:

> Hello,
> 
> On Thu, May 17, 2018 at 09:31:26PM -0400, Dan Norton wrote:
> > In another (non-minimal) system with a working DNS:
> > 
> > root@debU:~# apt search libjansson
> > [snip]
> > libjansson4/stable,now 2.9-1 amd64 [installed,automatic] 
> > C library for encoding, decoding and manipulating JSON data
> > 
> > Says it's installed but where? Running "whereis" turns up nothing.  
> 
> $ apt-file search libjansson.so.4
> libjansson4: /usr/lib/x86_64-linux-gnu/libjansson.so.4
> libjansson4: /usr/lib/x86_64-linux-gnu/libjansson.so.4.9.0
> 
> Also, for installed packages, "dpkg -L libjansson4".
> 

Thanks, Andy. dpkg -L found it. I didn't have apt-file installed.



NMI: IOCK error

2018-05-17 Thread Noah Duffy
I randomly started receiving messages on my server tonight, and I'm trying to 
figure out exactly what it means and how to go about fixing it.

The message from syslogd is:
kernel:[ 2939.389179] NMI: IOCK error (debug interrupt?) for reason 61 on CPU 0.

I did some Googling first, but I can't make too much of it.  It sounds like 
either a CPU error or some an issue with the system bus that might be 
motherboard related.  The processor is an Intel Atom C2550 if that helps any.

The motherboard/CPU is still under warranty, so if it is hardware related, I 
suppose I'll have to have someway to prove that to the manufacturer.

Any information on the specific error would be much appreciated.

Thanks in advance!

--
Noah Duffy



Re: making more room in root partition for distribution upgrade

2018-05-17 Thread Felix Miata
Mark Copper composed on 2018-05-17 18:06 (UTC-0500):

> There was a day when a 10 gb partition seemed like plenty of space to leave
> for the system but now it's not. An upgrade to Stretch appears to need more.
...
> What have other people done?

My largest Stretch root partition is 5.6GB. One or more of my 32 bit Stretch
installations may be on 4.8GB. All have separate partitions for /home and
/usr/local, none /opt or /usr. All are either EXT3 or EXT4. None have Cinnamon,
XFCE, Gnome, Mate, KDE or LibreOffice. Most have only IceWM and TDE. Nothing
stays in apt's cache for long, but I do have more than two installed kernels on
many of them. Also, all are kept svelte by APT::Install-Recommends "false";.
-- 
"Wisdom is supreme; therefore get wisdom. Whatever else you
get, get wisdom." Proverbs 4:7 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/



Re: GPG error when trying to update Lenny

2018-05-17 Thread David Wright
On Fri 18 May 2018 at 08:08:49 (+0900), Mark Fletcher wrote:
> On Wed, May 16, 2018 at 03:20:09PM +, Marie-Madeleine Gullibert wrote:
> > Hello to all, 
> > 
> > I'm relatively new to Debian. I'm helping out a small organization that has 
> > a library server installed on Debian to update their system. They run 
> > currently on Debian lenny so I'm first trying to upgrade the Debian system, 
> > but I keep running into a GPG error when I try to first update. I've tried 
> > many things but none have worked so far, and would gladly welcome any 
> > suggestions. I do have debian-archive-keyring installed (and up to date) 
> > and I've tried retrieving my expired keys from a two different keyservers 
> > to no avail. 
> > 
> > Here's what happens (I'm running as root): 
> > 
> > localhost:~# apt-get update
> > Get:1 http://archive.debian.org lenny Release.gpg [1034B]
> > Ign http://archive.debian.org lenny/main Translation-en_US
> > Get:2 http://archive.debian.org lenny/updates Release.gpg [836B]
> > Ign http://archive.debian.org lenny/updates/main Translation-en_US
> > Ign http://archive.debian.org lenny/updates/contrib Translation-en_US
> > Get:3 http://archive.debian.org lenny/volatile Release.gpg [481B]
> > Ign http://archive.debian.org lenny/volatile/main Translation-en_US
> > Hit http://archive.debian.org lenny Release
> > Hit http://archive.debian.org lenny/updates Release
> > Hit http://archive.debian.org lenny/volatile Release
> > Get:4 http://archive.debian.org lenny Release [99.6kB]
> > Get:5 http://archive.debian.org lenny/updates Release [92.4kB]
> > Ign http://archive.debian.org lenny Release
> > Get:6 http://archive.debian.org lenny/volatile Release [40.7kB]
> > Ign http://archive.debian.org lenny/updates Release
> > Ign http://archive.debian.org lenny/volatile Release
> > Ign http://archive.debian.org lenny/main Packages/DiffIndex
> > Ign http://archive.debian.org lenny/main Sources/DiffIndex
> > Ign http://archive.debian.org lenny/updates/main Packages/DiffIndex
> > Ign http://archive.debian.org lenny/updates/contrib Packages/DiffIndex
> > Ign http://archive.debian.org lenny/updates/main Sources/DiffIndex
> > Ign http://archive.debian.org lenny/updates/contrib Sources/DiffIndex
> > Ign http://archive.debian.org lenny/volatile/main Packages/DiffIndex
> > Ign http://archive.debian.org lenny/volatile/main Sources/DiffIndex
> > Hit http://archive.debian.org lenny/main Packages
> > Hit http://archive.debian.org lenny/main Sources
> > Hit http://archive.debian.org lenny/updates/main Packages
> > Hit http://archive.debian.org lenny/updates/contrib Packages
> > Hit http://archive.debian.org lenny/updates/main Sources
> > Hit http://archive.debian.org lenny/updates/contrib Sources
> > Hit http://archive.debian.org lenny/volatile/main Packages
> > Hit http://archive.debian.org lenny/volatile/main Sources
> > Fetched 235kB in 0s (301kB/s)
> > Reading package lists... Done
> > W: GPG error: http://archive.debian.org lenny Release: The following 
> > signatures were invalid: KEYEXPIRED 1520281423 KEYEXPIRED 1337087218
> > W: GPG error: http://archive.debian.org lenny/updates Release: The 
> > following signatures were invalid: KEYEXPIRED 1356982504
> > W: GPG error: http://archive.debian.org lenny/volatile Release: The 
> > following signatures were invalid: KEYEXPIRED 1358963195
> > W: You may want to run apt-get update to correct these problems
> > 
> 
> Since you want to upgrade the installation to a later version, my 
> suggestion is don't bother first trying to update Lenny. Just update 
> your sources.list to the next release (was that Jessie? I don't even 
> recall) and then update as usual.

No, squeeze is next. It might be worth looking at §4.4.5 in the
Release Notes so that the kernel and udev remain compatible.
The later upgrades don't AFAIK have a problem like that, but there
are changes, depending on your hardware, that might be worth checking
on. Eg to use 686 kernels in wheezy I think you need pae, and by the
time you reach stretch there are no 586 kernels I believe. You'll
probably also meet systemd, and booting should be faster but with
a more varied order of process startup.

Cheers,
David.



Re: Encrypted containers & the Debian installer.

2018-05-17 Thread Diagonal Arg



  On Wed, 16 May 2018 07:42:42 -0700 David Wright 
 wrote  
 > On Tue 15 May 2018 at 23:05:10 (-0700), Diagonal Arg wrote: 
 > > On my first tries with the Debian installer, I am struggling with the 
 > > limited resources for installing to encrypted disks.  I am using the same 
 > > technique I have used with Ubuntu, but failing at the last step: 
 > >  
 > > I create my luks disk(s) before-hand, then run the installer.  I find I 
 > > have to anna-install cryptsetup-udeb, as there is no such choice in "Load 
 > > Installer Modules".  Dropping to a shell, opening the disk, and  
 > > re-detecting hard drives allows me to carry out the installation (as long 
 > > as there's a filesystem in the mapped device), but on reboot I'm at an 
 > > initramfs without cryptsetup.  So I use a debian-live to pivot into the 
 > > system to create a crypttab.  I find I also have to install cryptsetup.  
 > > Then I run update-initramfs.  Here is where I'm stuck.  The new initramfs 
 > > still does not include cryptsetup.  Why is it not recognizing the 
 > > crypttab? 
 >  
 > Are you not seeing the last line in this screen excerpt? 
 >  
 >
 >   ┌┤ [?] Load installer components from CD 
 > ├┐
 >   │  
 >│
 >   │ All components of the installer needed to complete the install will be 
 > loaded   │
 >   │ automatically and are not listed here. Some other (optional) installer   
 >│
 >   │ components are shown below. They are probably not necessary, but may be  
 >│
 >   │ interesting to some users.   
 >│
 >   │  
 >│
 >   │ Note that if you select a component that requires others, those 
 > components  │
 >   │ will also be loaded. 
 >│
 >   │  
 >│
 >   │ Installer components to load:
 >│
 >   │  
 >│
 >   │[ ] choose-mirror: Choose mirror to install from (menu item)  
 > ↑  │
 >   │[ ] crypto-dm-modules-4.9.0-2-686-di: devicemapper crypto module  
 > ▮  │

David - thanks, but crypto-dm-modules does not include cryptsetup.

And, even when I anna-install it, it doesn't help with the other issues I 
mentioned above.

 > Cheers, 
 > David. 

/D



Re: filter network traffic of KVM guests.

2018-05-17 Thread Reco
Hi.

On Fri, May 18, 2018 at 10:47:11AM +1200, Richard Hector wrote:
> On 18/05/18 08:11, Reco wrote:
> >> I read it's deprecated to use iptables on a linux bridge. [1]
> > Yup, you should not.
> Interesting, I wasn't aware of that.

dmesg(1) says to this:

bridge: filtering via arp/ip/ip6tables is no longer available by
default. Update your scripts to load br_netfilter if you need this.

That's on stock Debian kernel version 4.9.
I tell you, reading logs leads to interesting discoveries sometimes ;).


> Does that just apply to running iptables on the host?

No. You need to have Linux bridge configured, and you need to apply at
least one netfilter rule to one of the bridge's slave interfaces. That's
then things start breaking.


> Or should I also not run it in the vm (eg on a rented VPS, where I
> assume the net device is backed by a bridge)?

You're safe ☺. Nobody's taking away your ability to configure netfilter
*inside* the VPS, that was working, and that will work. You VPS
provider, on the other hand, may have a huge headache.


> Presumably if it causes a security hole, I shouldn't be _able_ to run it
> in the VM?

No, it's not like this. For netfilter/iptables rules to apply every
packet that traverses brigde should register in several netfilter hooks
(parts of kernel code).

Either upstream is trying to unify exisiting netfilter_ip4,
netfilter_ipv6, netfilter_arp and whatever that thing called that's
utilized by ebtables. Currently these are four copy-pasted parts of
code.

Or they are aiming at performance gains - it's more or less common
knowledge that you don't use Linux kernel's IP stack starting with
40Gpbs, you bypass it as it's faster.

Reco



Re: NMI: IOCK error

2018-05-17 Thread Reco
Hi.

On Thu, May 17, 2018 at 09:20:44PM -0500, Noah Duffy wrote:
> I randomly started receiving messages on my server tonight, and I'm trying to 
> figure out exactly what it means and how to go about fixing it.
> 
> The message from syslogd is:
> kernel:[ 2939.389179] NMI: IOCK error (debug interrupt?) for reason 61 on CPU 
> 0.
> 
> I did some Googling first, but I can't make too much of it.  It sounds like 
> either a CPU error or some an issue with the system bus that might be 
> motherboard related.  The processor is an Intel Atom C2550 if that helps any.

[1] is very straightforward on it:

Use vendor hardware diagnostics software to analyse system health.
Contact the hardware manufacturer for further assistance.

So yes, you may have faulty hardware.


> The motherboard/CPU is still under warranty, so if it is hardware related, I 
> suppose I'll have to have someway to prove that to the manufacturer.

Relevant parts of dmesg should be a valid starting point. If possible,
try a different kernel (from the backports, for instance). If it's a
hardware - you'll have these NMI interrupts too.

Reco

[1] https://access.redhat.com/solutions/42261



Re: lightdm (testing): Long waiting time after login

2018-05-17 Thread Dino

On 18.05.2018 01:07 Ben Caradoc-Davies wrote:

On 17/05/18 21:02, Dino wrote:
Yes, you're right! When I wiggle the mouse the wait ends sooner. 
Indeed, if I don't move the mouse at all and don't press any key the 
screen just stays blank (I waited approx. 5 minutes and it still was 
black).
I attached the output of dmesg | grep "random". As you can see, "crng 
init done" appears after the 5 minutes I waited.


Yes, this seems to confirm my suspicion that something is blocking by 
calling getrandom without GRND_NONBLOCK.


Since there is no "splash" in my kernel command line in grub, I added 
"noplymouth" to it, but that didn't help. Maybe it's another package 
that calls getrandom without GRND_NONBLOCK. Let me know if I can 
support the investigation somehow.
The situation you describe does not implicate plymouth, because the 
pause occurs after you enter your credentials. This is a tricky one, 
because it could be lightdm, or systemd which is a known offender, 
xorg, or anything else in your session. This is a tricky problem to 
diagnose because, as soon as you start typing, your login will 
complete. I suggest reporting this against lightdm to get maintainer 
advice. The Debian Xfce and lightdm maintainer has commented on 
#897572 and is aware of the getrandom issue, but I could not find any 
lightdm issue for it.


Which iso image did you use to install testing?

Kind regards,

Seems like there is a related lightdm issue: 
https://github.com/CanonicalLtd/lightdm/issues/17
I added a comment pointing to the #897572 bug report. In addition, I 
also installed GDM to see whether the same problem occurs. Indeed, not 
even the login screen is shown before I have pressed some keys.


To install testing I used the latest weekly build of the netinstaller 
with non-free firmware (firmware-testing-amd64-netinst.iso).


Best regards,
Dino



Re: USB Install Fails, Complains about CD-ROM

2018-05-17 Thread Thomas Schmitt
Hi,

Mike Kupfer wrote:
> there seems to be something odd going on with the live image ISOs.
> [...]
>   alto$ sudo dd if=debian-live-9.4.0-amd64-xfce.iso of=/dev/sdb bs=32K
>   [...]
>   1951465472 bytes (2.0 GB, 1.8 GiB) copied, 455.702 s, 4.3 MB/s
>   alto$ sudo isosize -x /dev/sdb
>   sector count: 952848, sector size: 2048
> But 952848 * 2048 = 1951432704, not 1951465472.

That's indeed undesirable.
Interestingly debian-live-9.3.0-amd64-xfce.iso shows no such difference.

It looks like 9.4 was padded up to a full multiple of 64 KiB, whereas
the isosize of 9.3 was already aligned to 64 KiB.

My guess for now is that the reason is the multi-session preparation
which xorriso does by default if used with its native command set.
IIRC (after 10 years) this preparation includes session alignment to
full 32 blocks - 64 KiB.
The producer of Debian Live ISOs, live-wrapper, is one of the very few
producers of bootable ISOs which uses that command set. The others use
the mkisofs emulation, which omits the multi-session preparation by
default.

I will have to investigate deeper and probably ask the live-wrapper
maintainer to disable the multi-session preparation by command
  -compliance "no_emul_toc"

Thanks for pointing this out.


> I believe the problem is, in
> fact, the USB stick.  And not just the first one that I had problems
> with.  It looks like there's something about that entire make/model
> (MOSDART 8GB).

Let's hope they are not some of those fake capacity sticks. They pretend
to have their nominal storage capacity, offer the promised number of
logical blocks, but map them to a smaller number of physical blocks.
This makes them look as if they take all data. But in the end some of
the earlier written physical blocks get overwritten by later written
blocks with a different logical block address.


Have a nice day :)

Thomas