Bug#952286: libpostscriptbarcode: FTBFS: GPL Ghostscript 9.50: Unrecoverable error, exit code 1
On Sun, 23 Feb 2020 at 14:03, Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build > on amd64. As the package maintainer I acknowledge this bug and have prepared a fixed source package that have been refreshed against upstream (also me). This is currently being reviewed by the DD responsible for uploading. Thank you for alerting us of the issue.
Bug#700870: building eapol_test
Hi,
With eapol_test missing from Debian it is irksome to extend the
autopkgtests for the freeradius package to include testing of EAP
methods, and there are some good reasons to include such tests.
I have refreshed Matthew Newton's earlier patch against the latest
packaging source for wpa, and attached...
I've experienced no issues with building eapol_test from the upstream
repository over the last few years and this utility has been included
in the wpa_supplicant package of most RPM-based distributions for some
time. The utility is frequently used by those implementing AAA systems
and the upstream author is very responsive so I think that concerns
about the build quality of the tool are no longer founded.
Please could you review the decision to accept this patch to build an
eapol_test package (or roll it into the wpa_supplicant package)?
Many thanks,
Terry
diff --git a/debian/config/wpasupplicant/kfreebsd b/debian/config/wpasupplicant/kfreebsd
index 9bfc129..51834ad 100644
--- a/debian/config/wpasupplicant/kfreebsd
+++ b/debian/config/wpasupplicant/kfreebsd
@@ -191,7 +191,7 @@ CONFIG_HT_OVERRIDES=y
CONFIG_VHT_OVERRIDES=y
# Development testing
-#CONFIG_EAPOL_TEST=y
+CONFIG_EAPOL_TEST=y
# Select control interface backend for external programs, e.g, wpa_cli:
# unix = UNIX domain sockets (default for Linux/*BSD)
diff --git a/debian/config/wpasupplicant/linux b/debian/config/wpasupplicant/linux
index c12c17e..8be0243 100644
--- a/debian/config/wpasupplicant/linux
+++ b/debian/config/wpasupplicant/linux
@@ -191,7 +191,7 @@ CONFIG_HT_OVERRIDES=y
CONFIG_VHT_OVERRIDES=y
# Development testing
-#CONFIG_EAPOL_TEST=y
+CONFIG_EAPOL_TEST=y
# Select control interface backend for external programs, e.g, wpa_cli:
# unix = UNIX domain sockets (default for Linux/*BSD)
diff --git a/debian/control b/debian/control
index fa5e3d8..b43a30b 100644
--- a/debian/control
+++ b/debian/control
@@ -97,3 +97,13 @@ Description: Client support for WPA and WPA2 (IEEE 802.11i)
association with IEEE 802.11i networks.
.
This is a udeb of wpasupplicant for use by the debian-installer.
+
+Package: eapoltest
+Architecture: any
+Depends: ${shlibs:Depends},
+ ${misc:Depends}
+Description: EAPoL testing utility
+ eapol_test allows testing EAP authentication methods without using
+ a full 802.1X connection. It is frequently used to test the EAP
+ configuration of RADIUS systems. It is an administrator tool and not
+ required for standard 802.1X authentication.
diff --git a/debian/eapoltest.install b/debian/eapoltest.install
new file mode 100644
index 000..d3fe2c3
--- /dev/null
+++ b/debian/eapoltest.install
@@ -0,0 +1 @@
+wpa_supplicant/eapol_test usr/bin/
diff --git a/debian/eapoltest.lintian-overrides b/debian/eapoltest.lintian-overrides
new file mode 100644
index 000..45ffdbc
--- /dev/null
+++ b/debian/eapoltest.lintian-overrides
@@ -0,0 +1,6 @@
+# We distribute the package under the terms of the BSD license due to the
+# openssl issue, tell lintian to not complain:
+eapoltest: possible-gpl-code-linked-with-openssl
+
+# These are numerous and unlikely to be fixed anytime soon, filter them out.
+eapoltest: hyphen-used-as-minus-sign
diff --git a/debian/eapoltest.manpages b/debian/eapoltest.manpages
new file mode 100644
index 000..1c02297
--- /dev/null
+++ b/debian/eapoltest.manpages
@@ -0,0 +1 @@
+wpa_supplicant/doc/docbook/eapol_test.8
diff --git a/debian/rules b/debian/rules
index 9f68be3..8b15405 100755
--- a/debian/rules
+++ b/debian/rules
@@ -56,6 +56,9 @@ override_dh_auto_build:
dh_auto_build --sourcedirectory=hostapd \
--buildsystem=makefile
dh_auto_clean --sourcedirectory=src --buildsystem=makefile
+ # build eapol_test
+ dh_auto_build --sourcedirectory=wpa_supplicant \
+ --buildsystem=makefile -- eapol_test
override_dh_auto_clean:
dh_auto_clean --sourcedirectory=wpa_supplicant/doc/docbook \
@@ -91,6 +94,7 @@ override_dh_installchangelogs:
dh_installchangelogs --package=hostapd hostapd/ChangeLog
dh_installchangelogs --package=wpasupplicant wpa_supplicant/ChangeLog
dh_installchangelogs --package=wpagui wpa_supplicant/ChangeLog
+ dh_installchangelogs --package=eapoltest wpa_supplicant/ChangeLog
### end dh overrides
%:
Bug#792894: systemd unit files for isc-dhcp-server
Control: block 792894 by 826011 826012 On 31 May 2016 at 16:08, Terry Burton <t...@terryburton.co.uk> wrote: > Okay, I've now seen this [1] which blesses target units as a mechanism > for multiple service unit control, and the related open issue > regarding propagation of reload actions from targets to services [2] > (which doesn't affect isc-dhcp-server). > > So to make target units a first order citizen would require changes to > at init-system-helpers scripts [3] and systemd > (/lib/lsb/init-functions.d/40-systemd) [4]. Issues with patches raised: [1], [2]. Note that the "blocks" tags I've added are soft since we always have the less-preferable but simpler approach [3] vs this more thorough approach [4]. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826011 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826012 [3] https://github.com/terryburton/isc-dhcp-debian/tree/systemd-simple [4] https://github.com/terryburton/isc-dhcp-debian/tree/systemd
Bug#826012: /lib/lsb/init-functions.d/40-systemd: Support for compound target units as first-order services
Package: systemd
Version: 230-2
Severity: normal
This message [1] identifies that compound target units are the
appropriate mechanism for controlling multiple service units.
The LSB override hook currently only consider .service units, ignoring
compound .target units.
Support for this would be useful for providing systemd scripts for
multi-daemon services such as ISC DHCP server (with IPv4 and IPv6;
discussions ongoing here [2]) and PostgreSQL.
A patch for /lib/lsb/init-functions.d/40-systemd is attached. We probe
for a compound .target unit (having component services in the derived
ConsistsOf property) of matching service name invoking this as we
would a plain .service unit.
Would a maintainer kindly review? It may be desirable to coordinate
this with corresponding patches to the init-system-helpers scripts
[3].
[1] https://lists.freedesktop.org/archives/systemd-devel/2015-July/033628.html
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792894
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826011
Many thanks,
Terry
--- a/40-systemd 2016-06-01 11:55:20.885757279 +0100
+++ b/40-systemd 2016-06-01 12:00:21.42184 +0100
@@ -19,7 +19,11 @@
# Some services can't reload through the .service file,
# but can through the init script.
prog=${0##*/}
-service="${prog%.sh}.service"
+if [ "$(systemctl -p ConsistsOf show ${prog%.sh}.target)" != "ConsistsOf=" ]; then
+service="${prog%.sh}.target"
+else
+service="${prog%.sh}.service"
+fi
if [ "$(systemctl -p CanReload show $service 2>/dev/null)" = "CanReload=no" ] && [ "${1:-}" = "reload" ]; then
_use_systemctl=0
fi
@@ -51,7 +55,12 @@
;;
esac
-service="${prog%.sh}.service"
+# If there is an umbrella target for prog then use it
+if [ "$(systemctl -p ConsistsOf show ${prog%.sh}.target)" != "ConsistsOf=" ]; then
+service="${prog%.sh}.target"
+else
+service="${prog%.sh}.service"
+fi
# Don't try to run masked services. Don't check for errors, if
# this errors, we'll just call systemctl and possibly explode
Bug#826011: init-system-helpers: Support for compound target units as first-order services
Package: init-system-helpers
Version: 1.34
Severity: normal
This message [1] identifies that compound target units are the
appropriate mechanism for controlling multiple service units.
The sys-v compatibility helpers (service, {invoke,update}-rc.d,
debhelpers, et al.) currently only consider .service units, ignoring
compound .target units, when doing things such as overriding LSB
scripts, enabling/starting services, etc.
Support for this would be useful for providing systemd scripts for
multi-daemon services such as ISC DHCP server (with IPv4 and IPv6;
discussions ongoing here [2]) and PostgreSQL.
An example patch for /usr/sbin/service is attached. We probe for a
compound .target unit (having component services in the derived
ConsistsOf property) of matching service name invoking this as we
would a plain .service unit.
Would a maintainer kindly let me know whether this approach is
acceptable in which case I will extend it to all of the necessary
support scripts?
[1] https://lists.freedesktop.org/archives/systemd-devel/2015-July/033628.html
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792894
Many thanks,
Terry
--- a/service 2015-04-06 16:50:43.0 +0100
+++ b/service 2016-06-01 11:49:16.201754015 +0100
@@ -183,7 +183,12 @@
# systemctl calls.
if [ -n "$is_systemd" ]
then
- UNIT="${SERVICE%.sh}.service"
+ # If there is an umbrella target for the service then use it
+ if [ "$(systemctl -p ConsistsOf show ${SERVICE%.sh}.target)" != "ConsistsOf=" ]; then
+ UNIT="${SERVICE%.sh}.target"
+ else
+ UNIT="${SERVICE%.sh}.service"
+ fi
case "${ACTION}" in
restart|status)
exec systemctl ${ACTION} ${UNIT}
Bug#792894: systemd unit files for isc-dhcp-server
On 31 May 2016 at 14:53, Terry Burton <t...@terryburton.co.uk> wrote:
> On 27 May 2016 at 14:12, Marc Haber <mh+debian-b...@zugschlus.de> wrote:
>> On Fri, May 20, 2016 at 02:03:08AM +0100, Terry Burton wrote:
<...snip...>
>>> A general problem that I've noticed which might cause us to modify the
>>> isc-dhcp-server.target approach is that the following commands will
>>> not have the expected effect:
>>>
>>> service isc-dhcp-server {start,stop,restart}
>>> systemctl {start,stop,restart} isc-dhcp-server
>>>
>>> (1) It doesn't appear as though you can invoke .target unit files
>>> using /usr/sbin/service. This'll drive some purists nuts!
>>
>> I think this is something on systemd upstream's agenda to make people
>> migrate to the new, vendor lock-in interface asap.
>>
>>> (2) Additionally, these commands as-is will actually invoke LSB
>>> compatibility and trigger the sys-v init script rather than the native
>>> isc-dhcp-server.target unit file.
>>
>> Ouch. I consider this a bug in Debian's systemd packaging.
>>
>>> (3) The packaging would need to do something ensure that the
>>> isc-dhcp-server init script (via LSB) and isc-dhcp-server.target unit
>>> are not both started at boot.
>>
>> If this is a common issue for packages shipping both a sysv init
>> script and systemd units, it's up to systemd in Debian to fix this IMO.
>
> .service overrides LSB cleanly whereas .target does not. .target seems
> to be a powerful mechanism for controlling groups of service units
> under a single unit of control but it's not clear (to me) that that is
> precisely the intention of the systemd folks... I'm see if I can raise
> consensus about this. If it is intended that target to works in this
> way then it is clear that /usr/sbin/service should be patched to allow
> .target to override LSB.
Okay, I've now seen this [1] which blesses target units as a mechanism
for multiple service unit control, and the related open issue
regarding propagation of reload actions from targets to services [2]
(which doesn't affect isc-dhcp-server).
So to make target units a first order citizen would require changes to
at init-system-helpers scripts [3] and systemd
(/lib/lsb/init-functions.d/40-systemd) [4].
[1] https://lists.freedesktop.org/archives/systemd-devel/2015-July/033628.html
[2] https://github.com/systemd/systemd/issues/710
[3] https://sources.debian.net/src/init-system-helpers/1.34/script/
[4]
https://sources.debian.net/src/systemd/230-1/debian/extra/init-functions.d/40-systemd/
Bug#792894: systemd unit files for isc-dhcp-server
On 27 May 2016 at 14:12, Marc Haber <mh+debian-b...@zugschlus.de> wrote:
> On Fri, May 20, 2016 at 02:03:08AM +0100, Terry Burton wrote:
<...snip...>
Marc: Apologies. My mailer spammed your reply so I didn't read this
before posting my most recent update.
>> (1) I've added "Wants" to isc-dhcp-server.target which ensures that
>> subordinate services are started. Therefore you only need "enable" the
>> .target file to ensure that the v4 and v6 daemons are started assuming
>> they are configured.
>
> What did my Unit files do instead? I think I didn't need to manually
> enable them on my systems.
Mine (up to date Jessie) simply didn't attempt to start the
subcomponents but nevertheless set the target's state to running.
>> (2) In the -v4 service file I've replaced references to dhcpd4.conf
>> with dhcpd.conf since this provides compatibility across upgrades.
>
> I am not exactly sure what I actually filed in the bug, but locally I
> do have a Unit for dhcpd4.conf, one for dhcpd.conf and one for
> dhcp6.conf, preserving backwards compatibility while not given people
> the impression that IPv4 is still the default.
>
> Since a few years, IPv4 is officially deprecated in the RFCs and IPv6
> the default. Having a postfixless config file for v4 and a "special"
> file for v6 is the wrong way, things should be the other way round in
> 2016. Be advised that I'm being political here, the IPv6 rollout needs
> to be supported.
>
> I can live with this change though if it saves me from maintaining
> local packages. It makes me kind of sad though.
I'm on the same page here.
>> (3) I've added an EnvironmentFile option that reads the user provided
>> settings from /etc/default/isc-dhcp-server. I think only INTERFACES,
>> INTERFACESv4, INTERFACESv6 and possibly OPTIONS remain relevant for
>> reasons given in (8) and (9) below.
>
> systemd Upstream is, however, pondering to remove EnvironmentFile
> support since it was always wrong to have this in the first place. I
> got silenced on systemd-devel for having an opinioon and losing my
> temper over this issue.
<...snip...>
>> (8) Since you can't expand environment variables in the
>> ConditionPathExists and therefore refer directly to the config files
>> you may as well also hardcode the the values for DHCPDv{4,6}_CONF in
>> the ExecStart/ExecStartPre lines, i.e. don't read these from
>> /etc/default/isc-dhcp-server.
>
> Yes, that was one of the reasons why I ditched the defaults file
> entirely. Upstream wants people to edit unit files.
Hmm... Thanks for the info. Perhaps removing the defaults file is
ultimately the way to go.
Before then there would seem to be a missing piece at the packaging
infrastructure level to make Debian user's upgrade experience more
pleasant under such circumstances. It's also not clear that exposing
sysadmins directly to unit files is necessarily a positive step.
(Filed under bigger issues!)
>> A general problem that I've noticed which might cause us to modify the
>> isc-dhcp-server.target approach is that the following commands will
>> not have the expected effect:
>>
>> service isc-dhcp-server {start,stop,restart}
>> systemctl {start,stop,restart} isc-dhcp-server
>>
>> (1) It doesn't appear as though you can invoke .target unit files
>> using /usr/sbin/service. This'll drive some purists nuts!
>
> I think this is something on systemd upstream's agenda to make people
> migrate to the new, vendor lock-in interface asap.
>
>> (2) Additionally, these commands as-is will actually invoke LSB
>> compatibility and trigger the sys-v init script rather than the native
>> isc-dhcp-server.target unit file.
>
> Ouch. I consider this a bug in Debian's systemd packaging.
>
>> (3) The packaging would need to do something ensure that the
>> isc-dhcp-server init script (via LSB) and isc-dhcp-server.target unit
>> are not both started at boot.
>
> If this is a common issue for packages shipping both a sysv init
> script and systemd units, it's up to systemd in Debian to fix this IMO.
.service overrides LSB cleanly whereas .target does not. .target seems
to be a powerful mechanism for controlling groups of service units
under a single unit of control but it's not clear (to me) that that is
precisely the intention of the systemd folks... I'm see if I can raise
consensus about this. If it is intended that target to works in this
way then it is clear that /usr/sbin/service should be patched to allow
.target to override LSB.
For the time being my V2 patches (in some ways inferior to your V1
base) attempt to provide a path of least resistance to being included
in the isc-dhcp-server packaging.
I don't have the time (and patience) or standing within the Debian
community to work through all of the broader issues involved to make
your original approach work seamlessly but will have a little poke
where I can. /me ducks
Bug#792894: [PATCH] Re: Bug#792894: systemd unit files for isc-dhcp-server
On 20 May 2016 at 02:03, Terry Burton <t...@terryburton.co.uk> wrote:
<...snip...>
> A general problem that I've noticed which might cause us to modify the
> isc-dhcp-server.target approach is that the following commands will
> not have the expected effect:
>
> service isc-dhcp-server {start,stop,restart}
> systemctl {start,stop,restart} isc-dhcp-server
>
> (1) It doesn't appear as though you can invoke .target unit files
> using /usr/sbin/service. This'll drive some purists nuts!
> (2) Additionally, these commands as-is will actually invoke LSB
> compatibility and trigger the sys-v init script rather than the native
> isc-dhcp-server.target unit file.
> (3) The packaging would need to do something ensure that the
> isc-dhcp-server init script (via LSB) and isc-dhcp-server.target unit
> are not both started at boot.
>
> This could spoil an otherwise neat approach. Any suggestions welcome...
So it does not appear that using a target unit to aggregate a group of
service files into a single unit of service management is actually
aligned to the systemd developers' intentions. Rather target unit are
more focussed on machine states and boot processes akin to changing
runlevel in sys-v. Shame... The upshot is that patches to
/usr/sbin/service (in the sysvinit-utils package) to give the same
treatment to .target files as for .service files when overriding an
LSB script are unlikely to be accepted which scuppers the original
approach by Marc.
So please consider for inclusion this simplified approach [1] (also attached).
* We have distinct service files for V4 and V6 instances,
isc-dhcp-server.service and isc-dhcp-server-v6.service.
* They are both enabled and started by default...
* ... however they have a precondition on the relevant dhcpd{,6}.conf
file existing.
* They support INTERFACESv4 and INTERFACESv6 specified in
/etc/default/isc-dhcp-server.
* As with sys-v, we provide a deprecation warning if INTERFACES is
specified, but it is accepted for now.
* They support the OPTIONS parameter in /etc/default/isc-dhcp-server
(note that support for this is currently lacking in the sys-v script.)
* The DHCPDv{4,6}_PID options are not relevant to systemd and so are ignored.
* The DHCPDv{4,6}_CONF options are removed because ConditionPathExists
requires that these locations be hard-coded. If the user requires
these to be different then they can instead override the .service file
(overlay in /etc/systemd/system, etc.) as is more usual with systemd.
I hope this is acceptable.
[1]
https://github.com/terryburton/isc-dhcp-debian/commit/f2e4a1cd3c13ee2e77ee855267b24e30a597b562.diff
All the best,
Terry
diff --git a/debian/control b/debian/control
index f873489..9beb3ef 100644
--- a/debian/control
+++ b/debian/control
@@ -10,6 +10,7 @@ Build-Depends:
dpkg-dev (>= 1.13.2),
debhelper (>= 9.20151220),
dh-autoreconf,
+ dh-systemd (>= 1.5),
groff,
pkg-config,
po-debconf,
diff --git a/debian/isc-dhcp-server.isc-dhcp-server-v6.service
b/debian/isc-dhcp-server.isc-dhcp-server-v6.service
new file mode 100644
index 000..bb4e35c
--- /dev/null
+++ b/debian/isc-dhcp-server.isc-dhcp-server-v6.service
@@ -0,0 +1,10 @@
+[Unit]
+Description=ISC DHCP Server for IPv6 (dhcpd6.conf)
+After=network.target
+ConditionPathExists=/etc/dhcp/dhcpd6.conf
+
+[Service]
+EnvironmentFile=-/etc/default/isc-dhcp-server
+ExecStartPre=/usr/bin/touch /var/lib/dhcp/dhcpd6.leases
+ExecStartPre=/usr/sbin/dhcpd -f -t -6 -q $OPTIONS -cf /etc/dhcp/dhcpd6.conf
+ExecStart=/usr/sbin/dhcpd -f -6 -q $OPTIONS -cf /etc/dhcp/dhcpd6.conf
$INTERFACESv6
diff --git a/debian/isc-dhcp-server.service b/debian/isc-dhcp-server.service
new file mode 100644
index 000..072e6c9
--- /dev/null
+++ b/debian/isc-dhcp-server.service
@@ -0,0 +1,11 @@
+[Unit]
+Description=ISC DHCP Server for IPv4 (dhcpd.conf)
+After=network.target
+ConditionPathExists=/etc/dhcp/dhcpd.conf
+
+[Service]
+EnvironmentFile=-/etc/default/isc-dhcp-server
+ExecStartPre=/bin/sh -c '[ -n "$INTERFACES" -a -z "$INTERFACESv4"] && echo
"DHCPv4 interfaces are no longer set by the INTERFACES variable in
/etc/default/isc-dhcp-server. Please use INTERFACESv4 instead. Migrating
automatically for now, but this will go away in the future." >&2 || true'
+ExecStartPre=/usr/bin/touch /var/lib/dhcp/dhcpd.leases
+ExecStartPre=/usr/sbin/dhcpd -f -t -4 -q $OPTIONS -cf /etc/dhcp/dhcpd.conf
+ExecStart=/usr/sbin/dhcpd -f -4 -q $OPTIONS -cf /etc/dhcp/dhcpd.conf
$INTERFACESv4 $INTERFACES
diff --git a/debian/rules b/debian/rules
index b8358fc..627d98b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -37,7 +37,7 @@ CONFFLAGS+=--enable-use-sockets
endif
%:
- dh $@ --parallel --with autoreconf
+ dh $@ --parallel --with autoreconf,systemd
override_dh_auto_configure:
@@ -83,6 +83,7 @@ override_dh_install:
override_dh_installinit:
dh_installinit -Nisc-dhcp-server
Bug#792894: systemd unit files for isc-dhcp-server
Hi Marc, et al.
As you know from discussions on the dhcp-users mailing list I've been
threatening to do some systemd packaging work for ISC DHCP so I'm
taking your contributions as a starting point.
I can't speak for the Debian packaging team so maybe Michael Gilbert
can review this and let us know whether this is on track.
I've taken a look at your unit files and taken the liberty to create
some new ones based on them that I've added to my repo here [2].
I've used the latest Debian sys-v init script from the packaging
repository [3] as my reference for what's sane.
Compared to the originals units:
(1) I've added "Wants" to isc-dhcp-server.target which ensures that
subordinate services are started. Therefore you only need "enable" the
.target file to ensure that the v4 and v6 daemons are started assuming
they are configured.
(2) In the -v4 service file I've replaced references to dhcpd4.conf
with dhcpd.conf since this provides compatibility across upgrades.
(3) I've added an EnvironmentFile option that reads the user provided
settings from /etc/default/isc-dhcp-server. I think only INTERFACES,
INTERFACESv4, INTERFACESv6 and possibly OPTIONS remain relevant for
reasons given in (8) and (9) below.
(4) You use ConditionPathExists=/etc/dhcp/{dhcpd.conf,dhcpd6.conf} to
determine whether to start the units. I like this approach and have
kept it as it provides nice semantics in (5) and (6) below for whether
to start the v4 and v6 subcomponent services.
(5) Since a dhcpd6.conf file isn't currently installed by the package
(and probably shouldn't be, at least not yet) there is no attempt to
start a IPv6 instance - following the principle of least surprise. You
can simply add a dhcpd6.conf file and restart isc-dhcp-server.target
to enable the v6 instance.
(6) You can correspondingly disable the v4 instance by moving
dhcpd.conf out of the way.
(7) I note that this is a different condition for deciding whether or
not to start the daemon than the sys-v script which us whether or not
INTERFACESv{4,6} is defined in /etc/default/isc-dhcp-server. Such a
condition can't be done cleanly in systemd, i.e. you cannot have an
enabled service (or component of a compound target) that simply
decides not to start based on an arbitrary test). Perhaps the sys-v
init script can be aligned to the dhcpd{,6}.conf exists approach?
(8) Since you can't expand environment variables in the
ConditionPathExists and therefore refer directly to the config files
you may as well also hardcode the the values for DHCPDv{4,6}_CONF in
the ExecStart/ExecStartPre lines, i.e. don't read these from
/etc/default/isc-dhcp-server.
(9) I've dropped support for extracting OPTIONS (and OPTIONSv4,
OPTIONSv6) from /etc/default/isc-dhcp-server since it isn't honoured
by the most recent sysv-init script [3]. If this is accidental then
its trivial to add this back into both systemd and sys-v.
(10) Support for changing the PID file location in
/etc/default/isc-dhcp-server now seems a little odd given that we no
longer take the conf file from here so I've dropped it. This could
alternatively be passed in OPTIONSv{4,6} if we were to enable these.
A general problem that I've noticed which might cause us to modify the
isc-dhcp-server.target approach is that the following commands will
not have the expected effect:
service isc-dhcp-server {start,stop,restart}
systemctl {start,stop,restart} isc-dhcp-server
(1) It doesn't appear as though you can invoke .target unit files
using /usr/sbin/service. This'll drive some purists nuts!
(2) Additionally, these commands as-is will actually invoke LSB
compatibility and trigger the sys-v init script rather than the native
isc-dhcp-server.target unit file.
(3) The packaging would need to do something ensure that the
isc-dhcp-server init script (via LSB) and isc-dhcp-server.target unit
are not both started at boot.
This could spoil an otherwise neat approach. Any suggestions welcome...
I'm not intending to wire up the maintainer scripts until we have an
agreed approach so you'll have to hand-pick the unit files from my
repo [2] into {/etc,/lib}/systemd/system for the time being.
Would you mind taking a look to make sure these work for you, caveats
aside, and let me have any feedback.
[1] https://lists.isc.org/pipermail/dhcp-users/2016-May/020093.html
[2]
https://github.com/terryburton/isc-dhcp-debian/commit/26d3a94e00853f17141a6f748169dc2a26366b15
[3]
http://anonscm.debian.org/cgit/pkg-dhcp/isc-dhcp.git/tree/debian/isc-dhcp-server.init.d
Thanks.
Bug#824770: [PATCH] IPv6 instance fails to start if dhcpd6.leases file does not exist
Package: isc-dhcp-server Version: 4.3.4-1 Severity: normal Tags: patch The sys-v init script wrongly touches the v4 leases file when starting a v6 daemon. Also we should not touch the leases files when start is called and the daemon is already running. Please pull: https://github.com/terryburton/isc-dhcp-debian/commit/350949a7c43cf60459dd9d06b5b2497469dd16f8 As a patch: https://github.com/terryburton/isc-dhcp-debian/commit/350949a7c43cf60459dd9d06b5b2497469dd16f8.diff Thanks.
Bug#749272:
> I'll tag this as a "wishlist+wontfix" bug, and keep it open while waiting > for policy around the use of /etc/default from systemd, upstart, and other > init systems to settle. Simulating the sourcing of /etc/default/ by setting EnvironmentFile to it appears to have become common practice. Search "EnvironmentFile=\/etc\/default\/" at https://codesearch.debian.net/ Does this help with deciding this issue one way of the other? We currently override the .service file as follows (on Jessie): +EnvironmentFile=-/etc/default/varnish ExecStartPre=/usr/sbin/varnishd -C -f /etc/varnish/default.vcl -ExecStart=/usr/sbin/varnishd -a :6081 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m +ExecStart=/usr/sbin/varnishd $DAEMON_OPTS Hope this helps, Terry
Bug#703698:
Having just witnessed the same symptoms on our production service I performed a quick investigation. This revealed that dhcpd was iterating over a gettimeofday ... select loop in which select was returning immediately with three sockets to the failover peer that were in CLOSE_WAIT state. I was unable to debug further since restoring service was a priority. I shall add this to my ever growing list of failure modes for the ISC DHCP server failover implementation. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644906: [squeeze] e1000e: upstream workaround for packet drop on 82579LM at 100Mbps
On 11 March 2012 21:06, Holger Jeromin jero...@hitnet.rwth-aachen.de wrote: Jonathan Nieder schrieb am 11.03.2012 20:36: Holger Jeromin wrote: The patch (e1000e: workaround for packet drop on 82579 at 100Mbps) hit mainline in v3.1-rc4. Are squeeze 2.6.32.y kernels affected? As you can see in my smokeping there is still a paket loss in my internal network: http://www.katur.de/smokeping/smokeping.cgi?target=Local.Telefon It would be nice, if you can fix the problem with a new kernel for squeeze, since the paket loss is not nice for VoIP-Calls :-) Please test the attached patch, following instructions from [1]. ping -f 192.168.0.3 PING 192.168.0.3 (192.168.0.3) 56(84) bytes of data. --- 192.168.0.3 ping statistics --- 21499 packets transmitted, 21498 received, 0% packet loss, time 14026ms rtt min/avg/max/mdev = 0.207/0.616/17.595/0.240 ms, pipe 2, ipg/ewma 0.652/0.623 ms The kernel from squeeze had around 2% packet loss... The fix works very nice here. Thanks. I will keep the kernel until a new security update in stable forces me to update. Likewise, patch tested successfully. Thanks, Terry -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624794: Missing support for various storage and network
Regarding possible support for the Intel 82579LM and 82579V in Squeeze: Many (but not all) devices including an Intel 82579 series NIC have a hardware fault at 100Mbps that results in packet loss that is worked around by the following recent patch: http://patchwork.ozlabs.org/patch/109926/ Upstream commit: 0ed013e28fe853244f4972cf18d8e2bd62eeb8fc It would be necessary to cherry pick this in order for these NICs to function at 100Mbps. More detail is provided in bug #644096. Thanks, Terry -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644906: linux-2.6: e1000e: upstream workaround for packet drop on 82579LM at 100Mbps
Package: linux-2.6 Source: linux-2.6 Version: 3.0.0-3 Severity: normal Tags: patch Many (but not all) devices including an Intel 82579LM NIC have a hardware fault that results in packet loss at 100Mbps that is worked around by the following recent patch: http://patchwork.ozlabs.org/patch/109926/ More detail provided here: https://bugs.launchpad.net/ubuntu/oneiric/+source/linux/+bug/870127 https://bugzilla.redhat.com/show_bug.cgi?id=713315 It would be useful for this patch to be cherry picked for the kernel for Wheezy as this fault exists on a large number of recent devices. Thanks, Terry -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#557113: MAXBUF is defined too short for requests containing large cookies
Package: pound
Version: 2.4.3-1
Severity: important
Tags: patch
The MAXBUF constant defined at compile time was reduced upstream from
2048 to 1024 which results in line too long errors for requests that
contain large cookies:
Nov 18 16:25:07 ABC pound: (4361c950) line too long: Cookie: __abc= [...snip...]
The problem has been previously described in more detail here [1].
Most RPM-based distros have amended their SPEC files to pass
--with-maxbuf=2048 to ./configure [2].
We should do likewise, although I suggest using --with-maxbuf=4096 as
this is now the upstream default. (Patch below.)
[1]
http://www.apsis.ch/pound/pound_list/archive/2008/2008-02/1203715523000/index_html?fullMode=1#1203952046000
[2]
http://www.mail-archive.com/pld-cvs-com...@lists.pld-linux.org/msg155273.html
Thanks,
Terry
--- a/pound-2.4.3/debian/rules 2009-11-19 16:09:26.0 +
+++ b/pound-2.4.3/debian/rules 2009-11-19 16:10:01.0 +
@@ -36,7 +36,7 @@
dh_testdir
mv config.sub config.sub.upstream ln -s /usr/share/misc/config.sub
mv config.guess config.guess.upstream ln -s
/usr/share/misc/config.guess
- env LDFLAGS=$(LDFLAGS) CFLAGS=$(CFLAGS) ./configure
--prefix=/usr --mandir=\$${prefix}/share/man
--infodir=\$${prefix}/share/info --sysconfdir=/etc/pound
+ env LDFLAGS=$(LDFLAGS) CFLAGS=$(CFLAGS) ./configure
--prefix=/usr --mandir=\$${prefix}/share/man
--infodir=\$${prefix}/share/info --sysconfdir=/etc/pound
--with-maxbuf=4096
rm config.sub mv config.sub.upstream config.sub
rm config.guess mv config.guess.upstream config.guess
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534982: squid - DoS in external auth header parser
reopen 534982 severity 534982 critical This bug has recently hit us hard resulting in repeated DoS of a production web service running on Debian Lenny. What is the intended mitigation strategy for this DoS for users of Debian Stable who rely on Squid support for external_acl_type? For the time being I have had to rebuild appropriately patched squid packages for Lenny to guard against this. Since there will redoubtably be many production web servers running Debian that are vulnerable to CVE-2009-2855 the patch should be backported into the squid packages shipped with Lenny and released through the security repository. Thanks, Terry -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534982: squid - DoS in external auth header parser
On Wed, Sep 30, 2009 at 5:49 PM, Florian Weimer f...@deneb.enyo.de wrote: * Terry Burton: This bug has recently hit us hard resulting in repeated DoS of a production web service running on Debian Lenny. Do you know if this was triggered accidentally or deliberately? Florian, Probably accidentally, though it may possibly have been deliberate. (I will disclose further information privately as a follow up to this message.) Many thanks, Terry -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511768:
severity 511768 important # Raising severity since this bug makes the package unusable on a high volume or critical resolver -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#449430: Cannot cleanly override configuration file in /etc/default/pound
Package: pound Version: 2.0-1.2 Severity: wishlist At present, to specify an alternative configuration within /etc/default/pound you must use: ARGS=-f /srv/altconfig.cfg rather than the more simple: CONFIG=/srv/altconfig.cfg To get the expected behaviour, the definition of ARGS should be moved below the sourcing of /etc/default/pound within /etc/init.d/pound. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-5-686 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages pound depends on: ii libc6 2.3.6.ds1-13etch2 GNU C Library: Shared libraries ii libssl0.9.80.9.8c-4 SSL shared libraries pound recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326919: ITP: libpostscriptbarcode -- A barcode generator written entirely in PostScript
Package: wnpp Severity: wishlist Owner: Terry Burton [EMAIL PROTECTED] * Package name: libpostscriptbarcode Version : 20050808-1 Upstream Author : Terry Burton [EMAIL PROTECTED] * URL : http://www.terryburton.co.uk/barcodewriter/ * License : MIT/X Description : A barcode generator written entirely in PostScript Barcode Writer in Pure PostScript facilitates the printing of all major barcode symbologies entirely within PostScript. Since this resource is written in PostScript and interpretted within the virtual machine of a printer it is compatible with virtually any operating system and hardware platform. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.4.26-2-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316087: RFP: postscriptbarcode -- A barcode generator in pure PostScript
Package: wnpp Severity: wishlist * Package name: postscriptbarcode Version : Upstream Author : Terry Burton [EMAIL PROTECTED] * URL : http://www.terryburton.co.uk/barcodewriter/ * License : MIT/X Description : A barcode generator in pure PostScript Barcode Writer in Pure Postscript is an award-winning open source project, as used by NASA, that facilitates the printing of all major barcode symbologies entirely within level 2 PostScript. Hence the process of generating a printed barcode representing a given input is performed entirely within the printer (or print system) so that it is no longer the responsibility of your application or a library. The flexibility gained by this approach allows you to avoid the need to re-implement barcode generation code, or migrate to new libraries, whenever your language needs change. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.4.26-tez2.4 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
