Re: self identifying computer

[john doe]

On 6/5/2018 12:56 AM, mick crane wrote:
I changed the domain name for couple of home computers from "local" to 
"home"

one of them is win 10 PC.
I have ipfire box doing hopefully firewall and DNS and so while I 
changed domain I let all get address from its DHCP and gave them fixed 
leases.

I have 2 debian PCs
I try to find IP address of a cheap IP cctv camera I just bought with no 
instructions.

I do "nmap -sn 10.0.0.0/16" to see if camera shows up
oddly finds PCs but gets "I'm here" from the windows PC but on the old 
IP address I had previously given it in windows networking thingamyjig.


any idea where this identification might be hanging about ?
everything works but it just doesn't look very tidy.

I should point out I don't really know what I'm doing.



Welcome to the club, we've all been there!!! :)

You should look on the device on which you change the TLDS (local > 
home) for the dhcp leases and the log.


--
John Doe

Trouble with apt update

[Sonu Sirvee]

Hello all,
When I run the command: sudo apt update
I get this error:
$ sudo apt update
Ign:1 http://debianmirror.nkn.in/debian stretch InRelease
Hit:2 http://debianmirror.nkn.in/debian stretch-updates InRelease
Hit:3 http://debianmirror.nkn.in/debian stretch
Release
Hit:4 http://security.debian.org/debian-security stretch/updates
InRelease
Ign:6 http://ppa.edx.org stretch
InRelease
Err:7 http://ppa.edx.org stretch Release
  403  Forbidden
Reading package lists... Done
E: The repository 'http://ppa.edx.org stretch Release' does not have a
Release file.
N: Updating from such a repository can't be done securely, and is therefore
disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration
details.


Can someone help me out.
Thank you

Re: Update on my update problem with gnome system.

[David Wright]

On Sun 03 Jun 2018 at 20:05:39 (-0400), Kenneth Parker wrote:
> On Fri, May 25, 2018 at 10:02 PM, Kenneth Parker  wrote:
> 
> >
> >
> >>
> >> >dist-upgrade
> >> >dist-upgrade in addition to performing the function of
> >> upgrade, also intelligently
> >> >handles changing dependencies with new versions of packages;
> >> apt-get has a "smart"
> >> >conflict resolution system, and it will attempt to upgrade
> >> the most important packages
> >> >at the expense of less important ones if necessary. The
> >> dist-upgrade command may
> >> >therefore remove some packages. The /etc/apt/sources.list
> >> file contains a list of
> >> >locations from which to retrieve desired package files. See
> >> also apt_preferences(5)
> >> >for a mechanism for overriding the general settings for
> >> individual packages.
> >>
> >> Warning:  Ubuntu ("close enough" to Debian to confuse me, multiple years)
> > regularly requires dist-upgrade to do their frequent Kernel Upgrades,
> > because they change Version Numbers on, among other things, the vmlinuz
> > file.  So, when I do "apt-get upgrade" on the remaining Ubuntu Laptop, I
> > regularly see things like,
> >
> > 
> 
> Wow!  I said "bad things" about Ubuntu regarding this topic but, just
> today, experienced the same kind of thing, with Debian Stretch, regarding
> the vlc "uber Package".  Seems it's replacing libvlccore8 with libvlccore9,
> along with several other replacements!  So Debian also uses this technique
> (dist-upgrade) for, other than "Upgrading the Distribution".
> 
> Sorry about that, Ubuntu.  :-)
> 
> Kenneth Parker

Your criticism of Debian is unjustified.   apt-get dist-upgrade   is
required to upgrade libvlccore8 to libvlccore9 because, of course, the
latter is a different package.

libvlccore8 is based on VLC version 2 and libvlccore9 is based on VLC 3.
VLC is susceptible to DSA-4203 (CVE-2017-17670), so VLC 3 has been fixed
in 3.0.2. As VLC 2.x will not get fixed, stretch had no alternative
but to move from version 2 to 3.

Cheers,
David.

Re: [Debian-User] Re: [Debian-User] Re: Display image after resume

[Jim Popovitch]

On Tue, 2018-06-05 at 13:06 +1200, Ben Caradoc-Davies wrote:
> On 04/06/18 16:39, Jim Popovitch wrote:
> > On Mon, 2018-06-04 at 11:07 +1200, Ben Caradoc-Davies wrote:
> > > On 04/06/18 10:03, Jim Popovitch wrote:
> > > > What produces the desktop image that is displayed immediately
> > > > after
> > > > resuming from hibernation?
> > > > When resuming, I see the following in order:
> > > > 1. the boot screen
> > > > 2. a blank screen
> > > > 3. the actual desktop (live or a snapshot of it)
> > > > 4. the lockscreen password prompt
> > > > What I would like to do is prevent the actual desktop, or the
> > > > screenshot of it, from appearing after the system boots from
> > > > hibernation.
> > > 
> > > - What is your desktop?
> > 
> > Stretch Cinnamon
> > > - Are you using systemd?
> > 
> > Yes, but that is not an admission of preferring systemd. ;-)
> > > - How do you initiate hibernation? Via the desktop or via a
> > > keyboard
> > > or chassis button?
> > 
> > By closing the lid, it's a laptop (asus zenbook)
> > > - Which screen locker do you use? (e.g. light-locker or
> > > xscreensaver?)
> > 
> > cinnamon-screensaver
> > > This looks like a race condition in which system is hibernated
> > > before your screen is locked. I saw this for suspend when I let
> > > systemd manage my power button. My solution was to
> > > edit/etc/systemd/logind.conf to set HandlePowerKey=ignore and to
> > > let
> > > Xfce handle locking and suspend and Xfce Power Manager / Security
> > > /
> > > "Lock screen when system is going for sleep"). I use
> > > xscreensaver.
> > 
> > I think you're on to something.  When I CTRL+ATL+L the system, and
> > then
> > close the lid, the post-hibernation resume works correctly (no
> > screen
> > leakage).  Unfortunately changing the systemd login settings didn't
> > seem to have any effect.  I'm comfortable not using systemd on
> > servers,
> > is it just as straight forward without it on desktops/laptops?
> 
> I assume that after changing logind.conf you restarted (or similar)
> to reload your configuration.

Yes.  I tried reloading systemd, and then tried rebooting.

> 
> What are your values of these logind.conf settings (commented
> defaults 
> listed)?:
> 
> #HandleLidSwitch=suspend
> #HandleLidSwitchExternalPower=suspend
> #HandleLidSwitchDocked=ignore

Everything in my default logind.conf file was commented out. Based on
your feedback I set these keys+vals but the desktop leakage still
occurs. :-(

HandlePowerKey=ignore
HandleLidSwitch=ignore
HandleLidSwitchDocked=ignore
HandleLidSwitchExternalPower=ignore


> I have not used it, but you might investigate xss-lock to trigger a 
> screen lock based on a systemd hibernate event. Cinammon should do
> this for you, but it seems that it does not.
 
Thanks, I'll try xss-lock and look into filing a cinnamon bug.

Thanks for the help with this.

-Jim P.



signature.asc
Description: This is a digitally signed message part

Re: self identifying computer

[Ben Caradoc-Davies]

On 05/06/18 10:56, mick crane wrote:
I changed the domain name for couple of home computers from "local" to 
"home"

one of them is win 10 PC.
I have ipfire box doing hopefully firewall and DNS and so while I 
changed domain I let all get address from its DHCP and gave them fixed 
leases.

I have 2 debian PCs
I try to find IP address of a cheap IP cctv camera I just bought with no 
instructions.

I do "nmap -sn 10.0.0.0/16" to see if camera shows up
oddly finds PCs but gets "I'm here" from the windows PC but on the old 
IP address I had previously given it in windows networking thingamyjig.

any idea where this identification might be hanging about ?
everything works but it just doesn't look very tidy.
I should point out I don't really know what I'm doing.
mick


Your Windows PC will likely continue to use the static IP address set 
under Windows, as you told it to. If you want it to use a fixed IP 
address assigned for its MAC via DHCP, remove the IP address setting in 
Windows and let it use the address assigned via DHCP. Consumer-grade 
routers do not enforce IP address assignment so DHCP leases are just a 
suggestion (but like TCAS suggestions should be followed to avoid 
collisions).


The IP cctv camera might be getting its address from DHCP. You could try 
looking in your router DHCP lease table and eliminating known devices to 
deduce the IP and MAC address of the IP cctv camera. If you have no 
instructions or interface, I assume you have connected it over ethernet.


Kind regards,

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

Re: [Debian-User] Re: Display image after resume

[Ben Caradoc-Davies]

On 04/06/18 16:39, Jim Popovitch wrote:

On Mon, 2018-06-04 at 11:07 +1200, Ben Caradoc-Davies wrote:

On 04/06/18 10:03, Jim Popovitch wrote:

What produces the desktop image that is displayed immediately after
resuming from hibernation?
When resuming, I see the following in order:
    1. the boot screen
    2. a blank screen
    3. the actual desktop (live or a snapshot of it)
    4. the lockscreen password prompt
What I would like to do is prevent the actual desktop, or the
screenshot of it, from appearing after the system boots from
hibernation.

- What is your desktop?

Stretch Cinnamon

- Are you using systemd?

Yes, but that is not an admission of preferring systemd. ;-)

- How do you initiate hibernation? Via the desktop or via a keyboard
or chassis button?

By closing the lid, it's a laptop (asus zenbook)

- Which screen locker do you use? (e.g. light-locker or
xscreensaver?)

cinnamon-screensaver

This looks like a race condition in which system is hibernated
before your screen is locked. I saw this for suspend when I let
systemd manage my power button. My solution was to
edit/etc/systemd/logind.conf to set HandlePowerKey=ignore and to let
Xfce handle locking and suspend and Xfce Power Manager / Security /
"Lock screen when system is going for sleep"). I use xscreensaver.

I think you're on to something.  When I CTRL+ATL+L the system, and then
close the lid, the post-hibernation resume works correctly (no screen
leakage).  Unfortunately changing the systemd login settings didn't
seem to have any effect.  I'm comfortable not using systemd on servers,
is it just as straight forward without it on desktops/laptops?


I assume that after changing logind.conf you restarted (or similar) to 
reload your configuration.


What are your values of these logind.conf settings (commented defaults 
listed)?:


#HandleLidSwitch=suspend
#HandleLidSwitchExternalPower=suspend
#HandleLidSwitchDocked=ignore

I have not used it, but you might investigate xss-lock to trigger a 
screen lock based on a systemd hibernate event. Cinammon should do this 
for you, but it seems that it does not.


Kind regards,

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

Re: Debian 9 x64 wine32

[likcoras]

On 06/05/2018 03:57 AM, --- wrote:
> What i did:
> 
> Starting off with: apt install wine32
> 
> Reading the messages, adding libwine:i386 and tried "apt install" again
> 
> Reading again etc. adding step by step all requested (not suggested)
> packages.
> 
> So all in all i entered:
> 
> apt install wine32 libwine:i386 libglu1-mesa:i386 libldap-2.4-2:i386
> libpulse0:i386 libgl1-mesa-glx:i386 libdbus-1-3:i386 libsystemd0:i386
> libdrm2:i386

Huh, is apt not able to resolve those dependencies? aptitude handled
them for me just fine... Or not. Been a while since I installed wine on
this system, and I might have done some manual dependency resolution
with aptitude, can't recall.

> WARNING: Following packages will be removed . . . .
>   bsdutils libsystemd0 (wegen bsdutils) init systemd-sysv (wegen init)
> sysvinit-utils
>   util-linux (wegen sysvinit-utils)

Anyways, the problem's here, none of these packages are supposed to be
removed when installing wine.

Looking at libsystemd0, it has a few "breaks" relations to other
versions of libsystemd0 (on my system, libsystemd0:i386 !=
232-25+deb9u3) and I'm assuming apt is trying to install one of those
"bad" versions. Since you've explicitly stated that you want to install
libsystemd0:i386, apt decided that removing libsystemd0:amd64 is the
only option.

Not exactly sure how to do this with apt, but when I've had similar
issues from time to time when installing wine on other systems, I just
resolved dependencies manually using aptitude. It can be a bit
burdensome, but should work once you select the proper versions of core
packages so that they do not conflict with existing system packages, and
then let aptitude do the rest of the resolution for you.

That's the reason I still use aptitude, sometimes I really need to
manually resolve dependencies in order to avoid pulling in those bad
packages.

Good luck!

Re: Debian 9 x64 wine32

[davidson]

On Mon, 4 Jun 2018, --- wrote:


I have already activied the backports and did apt update afterwards.

I have tried

sudo apt-get install wine wine32 wine64 libwine libwine:i386 fonts-wine


If you do not specify that you want the version available from
backports, then the backports version will not be installed.

 https://wiki.debian.org/Backports#Installing_backports_on_the_command_line

Merely enabling the backports repository is not sufficient (though it
is of course necessary).

The second reply from Floris...

 https://lists.debian.org/msgid-search/c72b3530b07ae13c299db272a33d3...@dds.nl

...shows how to specify that you want to install the backports version
(with the "-t stretch-backports" part of the suggested command line
specifying the target release).


the result is the same . .


Yes, it would be.

Good luck with your project.

self identifying computer

[mick crane]

I changed the domain name for couple of home computers from "local" to 
"home"

one of them is win 10 PC.
I have ipfire box doing hopefully firewall and DNS and so while I 
changed domain I let all get address from its DHCP and gave them fixed 
leases.

I have 2 debian PCs
I try to find IP address of a cheap IP cctv camera I just bought with no 
instructions.

I do "nmap -sn 10.0.0.0/16" to see if camera shows up
oddly finds PCs but gets "I'm here" from the windows PC but on the old 
IP address I had previously given it in windows networking thingamyjig.


any idea where this identification might be hanging about ?
everything works but it just doesn't look very tidy.

I should point out I don't really know what I'm doing.

mick



--
Key ID4BFEBB31

Re: Debian 9 x64 wine32

[floris]

--- schreef op 2018-06-04 21:02:

I have already activied the backports and did apt update afterwards.

I have tried

sudo apt-get install wine wine32 wine64 libwine libwine:i386 fonts-wine


the result is the same . .


Christian




Can you post the output of:

sudo apt-get -t stretch-backports install wine wine32 wine64 libwine 
libwine:i386 fonts-wine


---
Floris

Re: Debian 9 x64 wine32

[---]

I have already activied the backports and did apt update afterwards.

I have tried

sudo apt-get install wine wine32 wine64 libwine libwine:i386 fonts-wine


the result is the same . .


Christian


Am 03.06.2018 um 20:32 schrieb floris:

uli...@web.de schreef op 2018-06-02 13:06:

Hi,

i am trying to install wine32 on a amd64 debian stretch system.

I added architecture i386

Using synaptic the package "wine32" is unknown

Using apt-get the package "wine32" is known, but needs libwine:i386.

Trying to install all dependencies results in a possible complete
chnage of the system-packages, which i have interrupted.

All infos, read from https://wiki.debian.org/Wine do not work.

What about the difference of finding "wine32" between apt-get and
synaptic?

BR

Christian



Please use the Wine version in strech-backports or from WineHQ. Wine 
1.8 (Stretch) is very old and isn't supported anymore.


After you have enabled the backports repo run:
sudo apt-get update
sudo apt-get install wine wine32 wine64 libwine libwine:i386 fonts-wine

If you want the WineHQ packages read:
https://wiki.winehq.org/Debian


---
Floris

Re: Debian 9 x64 wine32

[---]

What i did:

Starting off with: apt install wine32

Reading the messages, adding libwine:i386 and tried "apt install" again

Reading again etc. adding step by step all requested (not suggested) 
packages.


So all in all i entered:

apt install wine32 libwine:i386 libglu1-mesa:i386 libldap-2.4-2:i386 
libpulse0:i386 libgl1-mesa-glx:i386 libdbus-1-3:i386 libsystemd0:i386 
libdrm2:i386



The response was:

Following packages have been installed automatically and will be not 
necessary anymore:
  acl apg appstream argyll argyll-ref bc bogofilter bogofilter-bdb 
bogofilter-common brasero-common
  bubblewrap cdrdao cheese-common coinor-libcbc3 coinor-libcgl1 
coinor-libclp1 coinor-libcoinmp1v5
  coinor-libcoinutils3v5 coinor-libosi1v5 colord-data cracklib-runtime 
cups-server-common dc diffstat
  dleyna-server docbook-xml dosfstools dwz enchant espeak-ng-data 
evince-common evolution-common
  evolution-data-server-common exfat-fuse exfat-utils 
firebird3.0-common firebird3.0-common-doc
  firebird3.0-server-core folks-common fonts-droid-fallback 
fonts-opensymbol fonts-roboto-hinted
  foomatic-db-compressed-ppds freepats gcj-6-jre-lib gconf2-common 
gdebi-core gdisk gedit-common
  gir1.2-atk-1.0 gir1.2-freedesktop gir1.2-gck-1 
gir1.2-gdesktopenums-3.0 gir1.2-gdkpixbuf-2.0
  gir1.2-geoclue-2.0 gir1.2-geocodeglib-1.0 gir1.2-gmenu-3.0 
gir1.2-goa-1.0 gir1.2-gst-plugins-base-1.0
  gir1.2-gstreamer-1.0 gir1.2-gtop-2.0 gir1.2-ibus-1.0 
gir1.2-javascriptcoregtk-4.0 gir1.2-json-1.0
  gir1.2-notify-0.7 gir1.2-packagekitglib-1.0 gir1.2-pango-1.0 
gir1.2-rest-0.7 gir1.2-secret-1
  gir1.2-soup-2.4 gir1.2-tracker-1.0 gir1.2-upowerglib-1.0 
gir1.2-zeitgeist-2.0 gir1.2-zpj-0.0 git-man
  gnome-accessibility-themes gnome-control-center-data 
gnome-desktop3-data gnome-flashback-common
  gnome-icon-theme gnome-panel-data gnome-session-common 
gnome-shell-common gnome-software-common
  gnome-terminal-data gnome-themes-standard-data guile-2.0-libs 
gvfs-libs hp-ppd hplip-data
  hunspell-en-us icedtea-netx-common intltool-debian iputils-arping 
java-common javascript-common
  keyutils klibc-utils libaacs0 libabw-0.1-1 libao-common libao4 
libapache-pom-java libappstream-glib8
  libappstream4 libapr1 libaprutil1 libaprutil1-dbd-sqlite3 
libapt-pkg-perl libarchive-zip-perl
  libarchive13 libart-2.0-2 libass5 libasyncns0 libatasmart4 
libatk1.0-0 libatk1.0-data
  libatkmm-1.6-1v5 libavahi-common-data libavahi-common3 libavahi-core7 
libavahi-glib1 libbase-java
  libbcmail-java libbcpkix-java libbcprov-java libbdplus0 
libblas-common libblas3 libbluetooth3
  libbluray1 libboost-chrono1.62.0 libboost-date-time1.62.0 
libboost-filesystem1.62.0
  libboost-iostreams1.62.0 libboost-locale1.62.0 libboost-system1.62.0 
libboost-thread1.62.0
  libbrlapi0.6 libbs2b0 libburn4 libcairo-perl libcairomm-1.0-1v5 
libcamel-1.2-59 libcanberra0
  libcaribou-common libcdio-cdda1 libcdio-paranoia1 libcdr-0.1-1 
libcec4 libcgi-fast-perl
  libcgi-pm-perl libclass-accessor-perl libclone-perl 
libclucene-contribs1v5 libclucene-core1v5
  libclutter-1.0-common libcogl-common libcolamd2 libcolord2 
libcolorhug2 libcommons-codec-java
  libcommons-collections3-java libcommons-logging-java 
libcommons-parent-java libcompfaceg1 libcrack2
  libcrossguid0 libcrystalhd3 libcue1 libdc1394-22 libdca0 libde265-0 
libdee-1.0-4
  libdleyna-connector-dbus-1.0-1 libdleyna-core-1.0-3 libdotconf0 
libdrm-common libe-book-0.1-1
  libebackend-1.2-10 libebook-1.2-16 libebook-contacts-1.2-2 
libebur128-1 libecal-1.2-19
  libedata-book-1.2-25 libedata-cal-1.2-28 libedataserver-1.2-22 
libehcache-java libemail-valid-perl
  libenca0 libenchant1c2a libeot0 libepoxy0 libept1.5.0 liberror-perl 
libetpan17 libevdev2
  libevent-2.0-5 libexempi3 libexif12 libexiv2-14 libexttextcat-2.0-0 
libfaad2 libfbclient2
  libfile-chdir-perl libfile-copy-recursive-perl 
libfile-stripnondeterminism-perl libflite1
  libflute-java libfolks25 libfontenc1 libfonts-java libformula-java 
libfreehand-0.1-1 libfwupd1
  libgc1c2 libgcab-1.0-0 libgcj-bc libgcj-common libgcj17 libgck-1-0 
libgcr-3-common libgcr-base-3-1
  libgd3 libgdata-common libgdict-common libgeoclue-2-0 
libgeocode-glib0 libgexiv2-2 libgfbgraph-0.2-0
  libgfortran3 libgif7 libglapi-mesa libglib-perl libglibmm-2.4-1v5 
libgme0 libgmime-2.6-0
  libgnome-autoar-0-0 libgnome-autoar-common 
libgnome-games-support-common libgnome-keyring-common
  libgnome-menu-3-0 libgnomekbd-common libgoa-1.0-0b libgoa-1.0-common 
libgom-1.0-0 libgom-1.0-common
  libgpgmepp6 libgphoto2-6 libgphoto2-l10n libgphoto2-port12 
libgpod-common libgpod4 libgs9-common
  libgsasl7 libgsl2 libgsm1 libgsound0 libgspell-1-common 
libgtk-3-common libgtk2.0-common
  libgtksourceview-3.0-common libgtop-2.0-10 libgtop2-common libgusb2 
libgutenprint2 libgweather-common
  libgxps2 libharfbuzz-icu0 libhpmud0 libhsqldb1.8.0-java 
libhttp-parser2.1 libhunspell-1.4-0
  libhyphen0 libib-util libibus-1.0-5 libical2 libieee1284-3 
libijs-0.35 libimobiledevice6 libinput-bin
  libinput10 

Re: Not power off after shutdown in Jessie

[deloptes]

Miroslav Skoric wrote:

> Any idea?

yes this systemd thingie is cursed by design, so I have it pretty stable in
few devices where inevitable (phone, tablet etc) 

But everything else I install sysvinit-core and this makes it explicitly the
init process
(or add init=/lib/sysvinit/init to grub default kernel command line and
recreate initrd)

systemd is (still) not in position to handle stuff properly.

regards

Re: Not power off after shutdown in Jessie

[Miroslav Skoric]

On 05/31/2018 08:01 AM, Miroslav Skoric wrote:

After upgrading from Wheezy LTS to Jessie, one of my machines having 512 
MB RAM, does not power off when it reached target shutdown. It seems 
some old issue/bug with systemd or else. In fact, everything closes down 
properly except it does not unmount the following:


/run/user/1000
/run/user/106
/var
/home
/tmp

... and hangs there forever. That did not happen in Wheezy. Any idea?



Btw, after waiting for at least 3-4 hours for poweroff, I went to tty1 
console to try ctrl-alt-del there (because that did not work in tty7 
where the system left hanging). It did not help much there too, however 
I noticed two new lines there:


[74199.357014] systemd[1]: var.mount failed to run 'umount' task: Cannot 
allocate memory
[74199.380035] systemd[1]: home.mount failed to run 'umount' task: 
Cannot allocate memory



Any idea?

Re: What's the difference between the dialout and tty groups?

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Jun 04, 2018 at 10:51:01AM -0400, Stefan Monnier wrote:

[wall...]

> > It has since been superseded by Javascript, web page popups and
> > targeted ads.
> 
> The upside is that those powerful new tools are (pretty much) *only*
> available to those with the wrong hands.

You have a fine sense of irony :-)

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

iEYEARECAAYFAlsVUtkACgkQBcgs9XrR2kZIpQCeLyTyByfcTbgMzX2eoVbNsbTt
RE4AmwfU2kgyIPUGg+AjWVpQUCLVjP8G
=SwOL
-END PGP SIGNATURE-

Re: What's the difference between the dialout and tty groups?

[Stefan Monnier]

>> [...]  Wall, in the wrong hands
>> can be quite a nuisance so that's the sort of power one must be
>> careful about.  In this case, it doesn't really matter since I am
>> the only user.  
> It has since been superseded by Javascript, web page popups and
> targeted ads.

The upside is that those powerful new tools are (pretty much) *only*
available to those with the wrong hands.


Stefan

Re: .deb packages and security

[Darac Marjal]

On Mon, Jun 04, 2018 at 03:37:08PM +0200, john doe wrote:

On 6/4/2018 3:09 PM, Dan Purgert wrote:

Anil Duggirala wrote:

hello,
I know installing .deb packages downloaded from websites is not a good
practice in terms of software management in Debian. I would like to
know if I should have security concerns when installing a .deb package
"manually" (using gdebi for example) ?


Do you trust the provider of the *deb package?  If so, you should be
fine.  If you want to take it a step farther, see if there's a (sha256)
checksum for the package.



Note that checksum (sha512) and key verification are two separate things:

- checksum will insure that the file is not corrupted
- key verification will insure that the file has not been tempered with

So both steps is a must!


While checksums and signatures ensure that you get what was offered, 
reproducible builds ensure that what was offered is what you were 
promised (i.e. that the binary package is a true representation of the 
application).


--
For more information, please reread.


signature.asc
Description: PGP signature

Re: .deb packages and security

[john doe]

On 6/4/2018 3:09 PM, Dan Purgert wrote:

Anil Duggirala wrote:

hello,
I know installing .deb packages downloaded from websites is not a good
practice in terms of software management in Debian. I would like to
know if I should have security concerns when installing a .deb package
"manually" (using gdebi for example) ?


Do you trust the provider of the *deb package?  If so, you should be
fine.  If you want to take it a step farther, see if there's a (sha256)
checksum for the package.



Note that checksum (sha512) and key verification are two separate things:

- checksum will insure that the file is not corrupted
- key verification will insure that the file has not been tempered with

So both steps is a must!

--
John Doe

Re: Boot process related logs. What? Where?

[David Wright]

On Mon 04 Jun 2018 at 04:21:20 (-0500), Richard Owlett wrote:
> My explicit question is:
>Does an annotated list of boot process related log files and
>their locations exist?

Not AFAICT. But it's never to late to start writing a wiki.

> I did a reasonably typical install from DVD-1 of Debian 9.1.0 .

"reasonably typical". Not a lot of help.

> It is at least partly functional - I can log in as root.
> The only error message during boot was that it could not find a
> device with a specific UUID. It didn't stick around long enough to
> manually copy the string.
> 
> What is odd is that the last 5 characters match the UUID of the
> partition it is booting from.
> I need to know:
>   1. the complete UUID string
>   2. what was it looking for at the time

/var/log/kern.log and /var/log/messages will both normally
contain the kernel comand line that actually booted the system.
You could then reconcile that with the contents of /etc/fstab
and the /boot/grub/grub.cfg you think was used. (I am aware
that you typically mangle the installation of grub.)

ls -l /dev/disk/*uuid
will give you a list of potential UUIDs that the system might
be looking for. The probability is quite high that they are
all unique in as few as the last five characters.

> I know that many log files are under  /var/log/ .
> I used an operable system to examine the files on the failed
> partition and could not find a useful readable file. One file had an
> interesting name, but was apparently a binary file.

Yes, it would probably be an interesting name for the rest of us to
know, but I realise that it would not be typical for you to reveal it.

Cheers,
David.

Re: Not power off after shutdown in Jessie

[Curt]

On 2018-06-03, Miroslav Skoric  wrote:
>
> I did so, and noticed just some few Gnome -related things to be active 
> for the user 106 - myself? (although I logged out from the Mate desktop 
> and not from Gnome), as well as a few items active for user 1000 i.e. 
> root (such as 'sudo su' and 'systemd-cgls').
>
> Anyway, to be sure whether any of those processes were needed to run or 
> not, I did in parallel the same test with another slower machine running 
> Jessie at only 224MB RAM (also the recent upgrade from Wheezy), but 
> which one performs proper shutdown/poweroff.
>
> You bet, at both machines exactly the same processes were listed as 
> still running for user 106 and user 1000. However, only the better one 
> box having 512 MB RAM, does not power off when reached target shutdown.
>
> Any other thing to try?
>
>

I'm really too ignorant to be answering questions and should be asking some.

However I can't think of any.

Except: any clues in the logs?  

Look here:

 /usr/share/doc/systemd/README.Debian.gz

under

 Debugging boot/shutdown problems
 

which explains how to create a root debug shell on VT 9 available quite
late in the shutdown process; or, failing or in lieu of that, generating a
shutdown-log.txt file instead.

Good luck.

Re: .deb packages and security

[Dan Purgert]

Anil Duggirala wrote:
> hello,
> I know installing .deb packages downloaded from websites is not a good
> practice in terms of software management in Debian. I would like to
> know if I should have security concerns when installing a .deb package
> "manually" (using gdebi for example) ?

Do you trust the provider of the *deb package?  If so, you should be
fine.  If you want to take it a step farther, see if there's a (sha256)
checksum for the package.

> Is it possible that by downloading the skype .deb package and
> installing it, I am creating a security vulnerability in a Debian
> system?

Well, Skype is a Microsoft product ... :)


-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

Re: What's the difference between the dialout and tty groups?

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Jun 04, 2018 at 08:03:16AM -0500, Martin McCormick wrote:

[...]

> [...]  Wall, in the wrong hands
> can be quite a nuisance so that's the sort of power one must be
> careful about.  In this case, it doesn't really matter since I am
> the only user.  

It has since been superseded by Javascript, web page popups and
targeted ads.

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

iEYEARECAAYFAlsVOZsACgkQBcgs9XrR2kYeEwCbByOCz5dam31rZDhlpVLjX9fJ
G6YAnjP3QrGRkGLpZaUravNsufuaqoQ8
=2tfO
-END PGP SIGNATURE-

Re: .deb packages and security

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Jun 04, 2018 at 07:20:34AM -0500, Anil Duggirala wrote:
> hello,
> I know installing .deb packages downloaded from websites is not a good 
> practice in terms of software management in Debian. I would like to know if I 
> should have security concerns when installing a .deb package "manually" 
> (using gdebi for example) ?
> Is it possible that by downloading the skype .deb package and installing it, 
> I am creating a security vulnerability in a Debian system?

Yes.

I know, I know.

Take a step back: it all reduces to trust. Debian packages are signed
by their maintainers: by verifying the signature against the published
public keys (the Debian keyring) I can assess that the package comes
from a maintainer [1], and that it hasn't been tampered with in its way
to me (whether it was wget, curl, apt, file copy, or USB-on-pigeon).

Whether I trust the Debian maintainers is up to me...

Now where did you get your skype package? Is it signed? Do you have the
signer's public key? Can you assess whether this public key has reached
you without having been tampered with?

If you can answer those questions, then you have all of the above.

Now...

I don't know anything about the Debian skype package. But I *know* that
skype is not free. I doubt that the skype package brings along the skype
binaries: I expect it to be just an installer which grabs whatever
binaries are needed off the internets. And there's the real elephant
in the room.

Me? I wouldn't trust skype as far as I can spit. Personally I'd run it
in an isolated environment (if I had to, at all). Perhaps on its own
hardware. Raspis aren't that expensive these days.

Cheers

[1] ...or from someone who got control of the maintainer's private
   key.
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlsVOQcACgkQBcgs9XrR2kaJtACfWizxnxst6IeYOza1U3DEoZQZ
d3sAn06NK5pHnRV7BgmUI8nNndb2elFu
=Cmo4
-END PGP SIGNATURE-

Re: What's the difference between the dialout and tty groups?

[Martin McCormick]

Cindy-Sue Causey  writes:
> Hi, Martin.. I found these descriptions on the Debian Wiki
> SystemGroups page [0]:
> 
> tty: TTY devices are owned by this group. This is used by write and
> wall to enable them to write to other people's TTYs, but it is not
> intended to be used directly.
> 
> dialout: Full and direct access to serial ports. Members of this group
> can reconfigure the modem, dial anywhere, etc.
> 
> What's on the System Groups wiki page is about as far as I'm versed in
> it. So far, that's been enough *for me*. I, too, have read at least
> once out there that we need to be members of as few groups as possible
> for computer safety reasons.
> 
> Cindy :)

Thank you.  Interestingly enough, one of the programs I
wrote before retiring was a shell script which later turned in to a perl
program which constantly scanned the log of our dhcp servers for
Oklahoma State University, trolling for Mac addresses of
equipment that had been reported as stolen on campus.  It ran on
a FreeBSD unix box which has much the same general feel as Linux
but is philosophically somewhat different so, occasionally, you
run in to shell scripts or other types of programs that will run
perfectly on the box they were developed on but either run
slightly differently or not at all on the other.

When I matched a Mac address against our stolen goods
list, I used wall to mess up the screens of everybody else logged
in to our group unix work station to let them
know that the purloined machine was on our network and to
immediately call campus police, sometimes, a specific detective,
to tell them where the device was being used.

We cought a few thieves that way and had a few false
alarms when systems turned out not to be stolen but their owners
forgot to tell us there was no problem.  Wall, in the wrong hands
can be quite a nuisance so that's the sort of power one must be
careful about.  In this case, it doesn't really matter since I am
the only user.  

By the way, one of the thieves we cought stole somebody's
laptop one day and began using it in his job the very next day.
He was some campus department's IT support person, but not for
long.

Martin WB5AGZ

.deb packages and security

[Anil Duggirala]

hello,
I know installing .deb packages downloaded from websites is not a good practice 
in terms of software management in Debian. I would like to know if I should 
have security concerns when installing a .deb package "manually" (using gdebi 
for example) ?
Is it possible that by downloading the skype .deb package and installing it, I 
am creating a security vulnerability in a Debian system?
thanks,

Re: Boot process related logs. What? Where?

[songbird]

Richard Owlett wrote:
> My explicit question is:
> Does an annotated list of boot process related log files and
> their locations exist?

  /var/log/installer ?


> I did a reasonably typical install from DVD-1 of Debian 9.1.0 .
> It is at least partly functional - I can log in as root.
> The only error message during boot was that it could not find a device 
> with a specific UUID. It didn't stick around long enough to manually 
> copy the string.
>
> What is odd is that the last 5 characters match the UUID of the 
> partition it is booting from.
> I need to know:
>1. the complete UUID string
>2. what was it looking for at the time
>
> I know that many log files are under  /var/log/ .

  yes, and it helps to know what they all are...


> I used an operable system to examine the files on the failed partition 
> and could not find a useful readable file. One file had an interesting 
> name, but was apparently a binary file.

  is this system supposed to be running systemd?

  if so, create a /var/log/journal directory to get persistent
logs from systemd.

  then you can use journalctl to look at them.


  songbird

Boot process related logs. What? Where?

[Richard Owlett]

My explicit question is:
   Does an annotated list of boot process related log files and
   their locations exist?

I did a reasonably typical install from DVD-1 of Debian 9.1.0 .
It is at least partly functional - I can log in as root.
The only error message during boot was that it could not find a device 
with a specific UUID. It didn't stick around long enough to manually 
copy the string.


What is odd is that the last 5 characters match the UUID of the 
partition it is booting from.

I need to know:
  1. the complete UUID string
  2. what was it looking for at the time

I know that many log files are under  /var/log/ .
I used an operable system to examine the files on the failed partition 
and could not find a useful readable file. One file had an interesting 
name, but was apparently a binary file.

Re: Latest buster upgrade gets stuck -resolved

[Gary Dale]

On 2018-06-04 12:20 AM, Gary Dale wrote:
I'm running buster on an AMD64 system. I do an apt full-upgrade each 
night but tonight it's getting stuck. It seems to be building the 
initramfs image but having trouble with memtest86+. These are the last 
6 lines that it displays then stops. The terminal window isn't frozen 
- it responds to  for example by scrolling up.


Found initrd image: /boot/initrd.img-4.16.0-1-amd64
Found linux image: /boot/vmlinuz-4.15.0-3-amd64
Found initrd image: /boot/initrd.img-4.15.0-3-amd64
Found memtest86 image: /boot/memtest86.bin
Found memtest86+ image: /boot/memtest86+.bin
Found memtest86+ multiboot image: /boot/memtest86+_multiboot.bin

It originally got stuck on the apt full-upgrade. After waiting 15 or 
20 minutes, I killed the process and ran dpkg --configure -a but got 
the same results.


Any ideas?

I thought the problem may be related to linux-headers-4.16.0-2-amd64 
wasn't installed. This causes a problem setting up 
linux-image-4.16.0-2-amd64. However, after installing the headers, I'm 
still getting the same problem.


I also removed the various memtest86 packages since I don't really need 
them. Unfortunately the initramfs build still gets stuck.


Next I tried removing old kernel crud from /boot since apt seemed to be 
processing it when running the update-initramfs. Apt remove followed by 
a manual rm of the old files left me with just files related to the 4.16 
kernels.


I even tried rebooting to see if that cleared up the problem. It didn't. 
I did notice however that I had the old grub options, which is expected 
since the update-grub command probably never executed.


Any ideas?

-

Spoke too soon. After the reboot, the dpkg --configure -a did finally 
complete. It took a couple of minutes but it did finally returned to the 
command prompt.

Re: Latest buster upgrade gets stuck

[Gary Dale]

On 2018-06-04 12:20 AM, Gary Dale wrote:
I'm running buster on an AMD64 system. I do an apt full-upgrade each 
night but tonight it's getting stuck. It seems to be building the 
initramfs image but having trouble with memtest86+. These are the last 
6 lines that it displays then stops. The terminal window isn't frozen 
- it responds to  for example by scrolling up.


Found initrd image: /boot/initrd.img-4.16.0-1-amd64
Found linux image: /boot/vmlinuz-4.15.0-3-amd64
Found initrd image: /boot/initrd.img-4.15.0-3-amd64
Found memtest86 image: /boot/memtest86.bin
Found memtest86+ image: /boot/memtest86+.bin
Found memtest86+ multiboot image: /boot/memtest86+_multiboot.bin

It originally got stuck on the apt full-upgrade. After waiting 15 or 
20 minutes, I killed the process and ran dpkg --configure -a but got 
the same results.


Any ideas?

I thought the problem may be related to linux-headers-4.16.0-2-amd64 
wasn't installed. This causes a problem setting up 
linux-image-4.16.0-2-amd64. However, after installing the headers, I'm 
still getting the same problem.


I also removed the various memtest86 packages since I don't really need 
them. Unfortunately the initramfs build still gets stuck.


Next I tried removing old kernel crud from /boot since apt seemed to be 
processing it when running the update-initramfs. Apt remove followed by 
a manual rm of the old files left me with just files related to the 4.16 
kernels.


I even tried rebooting to see if that cleared up the problem. It didn't. 
I did notice however that I had the old grub options, which is expected 
since the update-grub command probably never executed.


Any ideas?