Monday, 16 January 2017

To access IPP-over-USB printer: Emulate remote machine in the network

tl;dr: Creating an emulated remote machine representing a USB printer as
it was a network printer, without VM with it's own kernel

Hi,

I am developing the ippusbxd daemon to support IPP-over-USB printers:

https://github.com/tillkamppeter/ippusbxd/

Modern network printers use IPP (Internet Printing Protocol) for clients
communicating with them. Also CUPS uses this protocol. In contrary
toolder, simpler protocols one cannot only simply send jobs (and pray)
but also request status info and, very important for driverless
printing, request information about the printer's capabilities.

To make all this possible on a USB printer (and even accessing the
printer's web admin interface) IPP-over-USB was introduced:

ftp://ftp.pwg.org//pub/pwg/ipp/whitepaper/draft-ippusbspecification-20110510.pdf

ippusbxd mirrors the IPP printer into the network, so that it can be
handled like a network printer, espocially to access the web interface
with a browser and to make CUPS and cups-browsed handle the printer like
a network printer.

In the beginning I used localhost:60000 which makes polling capabilities
and status, printing, and web interface work, but the printer could not
be Avahi-broadcasted and so CUPS and cups-browsed could not discover it.

Then I tried the "dummy" network device with an IPv6 ULA IP address.
This I could broadcast with Avahi and the broadcasts only appeared on
the local machine, as I wanted to have it, but I could only work with th
(awkward) IP address and not with host names, as Avahi broadcasts only
the one host name of the system and this hostname resolves only into the
system's network IP, not the IP of the dummy interface. Printing and
capability/status polling works IP-based, but not the web admin
interface of the printer.

See also my earlier discussion about this here on the list in the "Using
the dummy0 interface for a local-only service to be broadcasted by
Avahi" thread.

Now my new idea would be the following:

Is it possible to emulate a remote machine in the network, without
creating a virtual machine (with its own Linux kernel)?

The emulated remote machine should have its own IP (can be IPv6) and
host name (and ideally its own ports) and it should be on an interface
which supports multicast (like dummy, so that one can Avahi-broadcast
the emulated machine to the local machine). The emulation should by
fired up by ippusbxd and the printer be cuoled to that machine, so that
one can access the IPP-over-USB printer like a remote network printer,
ideally via hostname:631 for printing and hostname:80 for the web interface.

Is this possible?

Till



--
ubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: netplan and post-up/pre-down scripts

On 06/01/17 13:12, Mike Pontillo wrote:
> Long story short: in order to get the behavior I wanted, I wrote a
> custom script that monitors *operational status* (aka physical link
> up/down status), and I launch it using /e/n/i's `post-up`, and bring
> it down using /e/n/i's `pre-down` scripts.
>
> Looking at the `netplan` spec[4], I don't see a way to achieve that
> functionality. I know that many people are using the script-callout
> functionality in /e/n/i to achieve what they need to achieve, so it
> seems to me that having this in `netplan` is critical to achieving
> parity with what we have in Xenial with `ifupdown`.
>
> In an ideal world, I think `netplan` would be able to model my use
> case out-of-the-box.[5] But since we can't expect to model everyone's
> use case, it seems like custom scripting functionality is a hard
> requirement, though perhaps one that could have tricky cross-platform
> implications.

Would 'got-link' and 'lost-link' be good names for this?

Mark

--
ubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Saturday, 14 January 2017

Proposal: removing net-tools from ubuntu-minimal in 17.04

Hi all,

Starting last month, Debian has been discussing dropping net-tools[1], which
prompted me to review its status in Ubuntu. This package, which provides
various commands like ifconfig and netstat, is currently part of
ubuntu-minimal. However, the tools in this package are largely considered
superseded by iproute2, providing 'ip' and 'ss' tools that interface much
better with modern kernels. And iproute2 is also part of ubuntu-minimal.

Is there a reason to keep net-tools in ubuntu-minimal, or should we remove
it from the minimal set for 17.04? Packages / flavors that want it can
still depend on it (which they should technically already be doing anyway).

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
[email protected] [email protected]

[1] https://lists.debian.org/debian-devel/2016/12/msg00604.html

Thursday, 12 January 2017

Re: Make systemd journal persistent | remove rsyslog (by default)

On Thu, 2017-01-12 at 10:50 -0500, Bryan Quigley wrote:
> We could explicitly keep rsyslog supported in main for at least 18.04
> for the for those who need it (or indefinitely if we find it's still
> needed for remote enterprise logging).   I was thinking that we might
> have to keep it in main until 18.04 anyway for upgrades.
>
I think this would be a hard requirement if it was decided on the switch.

Another thing that came to mind is 'logcheck' (in main) for log auditing and I
don't think it understands systemd-journald log format. logcheck is not
installed by default of course, but it is another package useful in enterprise
environments. If the standard logs are removed, then installing logcheck won't
work by default and additional steps need to be performed to install rsyslog
(and make sure systemd-journald forwards to it).

There are two things here:
1. make systemd journal persistent
2. avoid duplicate logs from rsyslog

Why not just do '1' and let rsyslog remain? The standard logs are rotated so
this shouldn't be overly burdensome. Have you measured how much the duplicate
logs would take on a typical system?

> Kind regards,
> Bryan
>
>
> On Wed, Jan 11, 2017 at 5:32 PM, Jamie Strandboge <[email protected]> wrote:
> >
> > On Wed, 2017-01-11 at 08:29 +0100, Martin Pitt wrote:
> > >
> > > Jamie Strandboge [2017-01-10 16:27 -0600]:
> > > >
> > > >
> > > > Remote logging. Rsyslog is far superior in this regard. Granted, remote
> > > > logging
> > > > is not enabled by default but it is a requirement in many environments.
> > > The systemd-journal-remote package does provide the necessary tools and is
> > > reasonably flexible (push or pull, builtin https or using arbitrary ports
> > > which
> > > you e. g.  could forward through ssh). It might not be as flexible as
> > > rsyslog,
> > > but as one needs to set up remote logging manually anyway, you always have
> > > the
> > > possibility of picking rsyslog, journal, or even something else.
> > >
> > Yes, but the 'logged to' system needs to be running systemd[1]. rsyslog
> > speaks
> > the standard syslog protocol on 514/udp, but systemd-journal does not.
> >
> > [1]https://www.freedesktop.org/software/systemd/man/systemd-journal-remote.h
> > tml
> >
> > --
> > Jamie Strandboge             | http://www.canonical.com
> >
> >
> > --
> > ubuntu-devel mailing list
> > [email protected]
> > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo
> > /ubuntu-devel
> >
--
Jamie Strandboge | http://www.canonical.com

Wednesday, 11 January 2017

Re: Make systemd journal persistent | remove rsyslog (by default)

On Wed, 2017-01-11 at 08:29 +0100, Martin Pitt wrote:
> Jamie Strandboge [2017-01-10 16:27 -0600]:
> >
> > Remote logging. Rsyslog is far superior in this regard. Granted, remote
> > logging
> > is not enabled by default but it is a requirement in many environments.
> The systemd-journal-remote package does provide the necessary tools and is
> reasonably flexible (push or pull, builtin https or using arbitrary ports
> which
> you e. g.  could forward through ssh). It might not be as flexible as rsyslog,
> but as one needs to set up remote logging manually anyway, you always have the
> possibility of picking rsyslog, journal, or even something else.
>
Yes, but the 'logged to' system needs to be running systemd[1]. rsyslog speaks
the standard syslog protocol on 514/udp, but systemd-journal does not.

[1]https://www.freedesktop.org/software/systemd/man/systemd-journal-remote.html

--
Jamie Strandboge | http://www.canonical.com

Re: Make systemd journal persistent | remove rsyslog (by default)

hi,
Am Mittwoch, den 11.01.2017, 08:29 +0100 schrieb Martin Pitt:
> Jamie Strandboge [2017-01-10 16:27 -0600]:
> >
> > Remote logging. Rsyslog is far superior in this regard. Granted,
> > remote logging
> > is not enabled by default but it is a requirement in many
> > environments.
> The systemd-journal-remote package does provide the necessary tools
> and is
> reasonably flexible (push or pull, builtin https or using arbitrary
> ports which
> you e. g.  could forward through ssh). 

well, will it blend in in an existing remote rsyslog logging
environment in a datacenter ? i guess having an existing central
rsyslog server that you want to hook in to with a newly set up machine
is a typical usecase.

ciao
oli

Re: Make systemd journal persistent | remove rsyslog (by default)

> From: [email protected] [mailto:ubuntu-devel-
>
> Jamie Strandboge [2017-01-10 16:27 -0600]:
> > Remote logging. Rsyslog is far superior in this regard. Granted,
> remote logging
> > is not enabled by default but it is a requirement in many
> environments.
>
> The systemd-journal-remote package does provide the necessary tools and is
> reasonably flexible (push or pull, builtin https or using arbitrary ports
> which
> you e. g. could forward through ssh). It might not be as flexible as
> rsyslog, but as one needs to set up remote logging manually anyway, you
> always
> have the possibility of picking rsyslog, journal, or even something else.

I have done a POC with systemd-journal-remote yet, but that sounds quite good.
In our production environment following features should be supported also by
Rsyslog replacements to support current usecases and ease gradual rollout:

1) rsyslog RELP mode (reliable remote transport) - reduces probability for
lost messages during network maintenance, e.g. statefull firewall restarts
without conntrack failover.

2) Remote log data caching on network downtimes - data should be transmitted
when network up again

3) Cascading operation: branch offices or guest perform remote logging to a
nearby concentrator, only the concentrator has to be granted off-site access
in firewall

4) TLS support with own CA - each new machine will get a new certificate from
deployment system, central logging should accept traffic from all those
machines with valid certificate automatically (eases automatic rollout)

5) rsyslog/system hybrids: in early phase there will be e.g. some old rsyslog
based LXC containers forwarding logs to systemd-only hosts and perhaps also
vice versa.

6) Streams > 10GB logs/day should not cause any troubles, log data losses.

7) Integration with SIEMs or logmanagement solutions, e.g. graylog.

Perhaps not all those features are possible/sensible to have
systemd-journal-remote. In that case another requirement could arise:

8) Allow local rsyslog/systemd-journal-remote combination: systemd forwards
the logs to a local rsyslog (which might also process other remote data from
requirement 3), and all the really remote forwarding will happen using
old-style rsyslog. Of course this would require maintenance of automation
scripts for setup/automatic configuration of both rsyslog/systemd in various
flavours (host/LXC-guest, Trusty/Xenial/CentOS)


I put it on my list, that I have to do a ~3 machine POC with
systemd-journal-remote only setup to check all those requirements. As rsyslog
is not completely trouble-free, this might help cut down costs in the long
run.

Roman