Bug#788354: AW: Bug#788354 closed by Michael Lustfield mich...@lustfield.net ()
Hello Michael, sorry for the bogus nginx vhost configuration file. There had been a copypaste error. See the attached vhost configuration that will a) load without any errors, and b) uses set $aid $arg_id to show you that arg_id is actually never set Regards Carsten -- Carsten Klein Entwickler/Webentwicklung T +49 (0)221 2587 492 F +49 (0)221 2587 491 E carsten.kl...@bva-media.de I www.bva-media.de BVA Bielefelder Verlag GmbH Co. KG Standort Köln Friesenplatz 16 50672 Köln - Sitz der Gesellschaft: Bielefeld - HRA 8161 AG Bielefeld Persönlich haftende Gesellschafterin: Gundlach Beteiligungsgesellschaft mbH Bielefeld, HRB 7025 AG Bielefeld -Ursprüngliche Nachricht- Von: Debian Bug Tracking System [mailto:ow...@bugs.debian.org] Gesendet: Freitag, 12. Juni 2015 19:51 An: Carsten Klein Betreff: Bug#788354 closed by Michael Lustfield mich...@lustfield.net () This is an automatic notification regarding your Bug report which was filed against the nginx package: #788354: AW: Bug#788348: nginx: $arg_id is always undefined It has been closed by Michael Lustfield mich...@lustfield.net. Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Michael Lustfield mich...@lustfield.net by replying to this email. -- 788354: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788354 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems arg_id.vhost Description: arg_id.vhost
Bug#788348: nginx: $arg_id is always undefined
Package: nginx
Version: 1.6.2-5
Severity: important
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
Having a rule like so in the nginx configuration
location ^~ /foo/bar/news.php {
if ($arg_id ~ [0-9]+) {
rewrite ...;
}
}
Please note that in older nginx versions this worked just fine. It seems that
it was
broken with the introduction of nginx 1.6.2 or the version before that.
* What exactly did you do (or not do) that was effective (or
ineffective)?
I pointed my browser to http://localhost/foo/bar/news.php?id=1234.
* What was the outcome of this action?
In the error.log it says that the rule could not be applied and that $arg_id was
undefined.
* What outcome did you expect instead?
$arg_id should have had the value 1234 and the rule should have been applied
along
with also the rewrite directive.
*** End of the template - remove these template lines ***
-- System Information:
Debian Release: 8.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.18.9-x86_64-jb1 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages nginx depends on:
ii nginx-full 1.6.2-5
nginx recommends no packages.
nginx suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#788354: AW: Bug#788348: nginx: $arg_id is always undefined
Package: nginx
Version: 1.6.2-5
Severity: important
See the attachment for a working configuration that exposes three different
locations using different rules, loc1, loc2 and loc3.
Using the following URLs, you can reproduce the erroneous behavior:
http://localhost:81/loc1?id=12name=foo
http://localhost:81/loc2?id=12name=foo
http://localhost:81/loc3?id=12name=foo
TIA for your help!
Carsten
-Ursprüngliche Nachricht-
Von: Michael Lustfield [mailto:mich...@lustfield.net]
Gesendet: Mittwoch, 10. Juni 2015 15:38
An: Carsten Klein; 788...@bugs.debian.org
Cc: Debian Bug Tracking System
Betreff: Re: Bug#788348: nginx: $arg_id is always undefined
We would need to see your entire unmodified configuration file to help with
this. Additionally, it is MUCH better to use a map directive for most cases
where $arg_ARG is used.
On Wed, Jun 10, 2015 at 7:53 AM, Carsten Klein carsten.kl...@bva-media.de
wrote:
Package: nginx
Version: 1.6.2-5
Severity: important
Dear Maintainer,
*** Reporter, please consider answering these questions, where
appropriate ***
* What led up to the situation?
Having a rule like so in the nginx configuration
location ^~ /foo/bar/news.php {
if ($arg_id ~ [0-9]+) {
rewrite ...;
}
}
Please note that in older nginx versions this worked just fine. It
seems that it was broken with the introduction of nginx 1.6.2 or the version
before that.
* What exactly did you do (or not do) that was effective (or
ineffective)?
I pointed my browser to http://localhost/foo/bar/news.php?id=1234.
* What was the outcome of this action?
In the error.log it says that the rule could not be applied and that
$arg_id was undefined.
* What outcome did you expect instead?
$arg_id should have had the value 1234 and the rule should have been
applied along with also the rewrite directive.
*** End of the template - remove these template lines ***
-- System Information:
Debian Release: 8.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.18.9-x86_64-jb1 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages nginx depends on:
ii nginx-full 1.6.2-5
nginx recommends no packages.
nginx suggests no packages.
-- no debconf information
Bug#788348: AW: Bug#788348: nginx: $arg_id is always undefined
See the attachment for a working configuration that exposes three different
locations using different rules,
loc1, loc2 and loc3.
Using the following URLs, you can reproduce the erroneous behavior:
http://localhost:81/loc1?id=12name=foo
http://localhost:81/loc2?id=12name=foo
http://localhost:81/loc3?id=12name=foo
TIA for your help!
Carsten
-Ursprüngliche Nachricht-
Von: Michael Lustfield [mailto:mich...@lustfield.net]
Gesendet: Mittwoch, 10. Juni 2015 15:38
An: Carsten Klein; 788...@bugs.debian.org
Cc: Debian Bug Tracking System
Betreff: Re: Bug#788348: nginx: $arg_id is always undefined
We would need to see your entire unmodified configuration file to help with
this. Additionally, it is MUCH better to use a map directive for most cases
where $arg_ARG is used.
On Wed, Jun 10, 2015 at 7:53 AM, Carsten Klein carsten.kl...@bva-media.de
wrote:
Package: nginx
Version: 1.6.2-5
Severity: important
Dear Maintainer,
*** Reporter, please consider answering these questions, where
appropriate ***
* What led up to the situation?
Having a rule like so in the nginx configuration
location ^~ /foo/bar/news.php {
if ($arg_id ~ [0-9]+) {
rewrite ...;
}
}
Please note that in older nginx versions this worked just fine. It
seems that it was broken with the introduction of nginx 1.6.2 or the version
before that.
* What exactly did you do (or not do) that was effective (or
ineffective)?
I pointed my browser to http://localhost/foo/bar/news.php?id=1234.
* What was the outcome of this action?
In the error.log it says that the rule could not be applied and that
$arg_id was undefined.
* What outcome did you expect instead?
$arg_id should have had the value 1234 and the rule should have been
applied along with also the rewrite directive.
*** End of the template - remove these template lines ***
-- System Information:
Debian Release: 8.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.18.9-x86_64-jb1 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages nginx depends on:
ii nginx-full 1.6.2-5
nginx recommends no packages.
nginx suggests no packages.
-- no debconf information
arg_id.vhost
Description: arg_id.vhost
Bug#783271: When configuring custom logging in /etc/krb5.conf,, xrb5 services are unable to write to these log files as they are not, permitted in the service configuration used by systemd
I think that I can live with the solution proposed by Russ as it is universal and can be applied to all services requiring RW access to locations/files other than the default, thanks!
Bug#783271: When configuring custom logging in /etc/krb5.conf,, xrb5 services are unable to write to these log files as they are not, permitted in the service configuration used by systemd
Package: help Version: krb5-admin-server Severity: grave When configuring custom logging in /etc/krb5.conf, xrb5 services are unable to write to these log files as they are not permitted in the service configuration used by systemd Having a logging configuration like [logging] kdc = FILE:/var/log/krb5/kdc.log admin_server = FILE:/var/log/krb5/kadmin.log default = FILE:/var/log/krb5/kadmin.log in the /etc/krb5.conf configuration file, it will prevent both the services krb5-admin-server and krb5-kdc from working correctly as these services are not permitted to write to these locations as per the default systemd service descriptors. Symptons of this problem are for example if your add a (user) principle to the database using kadmin.local, it will create the principal as expected. Now, when using kadmin -p principal you will be able to log in and use the administrative console. If you reboot or restart the respective services, kadmin -p principal will fail due to both krb5-admin-server and krb5-kdc being unable to write to their log files. The same is true if you add that principal and try to kadmin -p admin and then try to add for example a host principal. The then presented error message is unrelated to actual error, namely it being unable to write to its log files. I don't know how to fix this with the current systemd. Any hints? Please note that this applies to both testing/sid and I need it to be fixed on testing aka jessie. TIA! -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742320: lxc: Missing dependency towards rsync - lxc-create requires it
Package: lxc Version: 0.9.0~alpha3-2+deb8u1 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Installing lxc did not install required dependencies. * What exactly did you do (or not do) that was effective (or ineffective)? Tried to create a container from a template: SUITE=jessie lxc-create -n TEST -t debian * What was the outcome of this action? When trying to copy the rootfs to /var/lib/lxc/TEST, the operation failed due to rsync being unavailable. * What outcome did you expect instead? Creation of the container should not have failed and when installing lxc, the dependency towards rsync should be resolved automatically. *** End of the template - remove these template lines *** -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lxc depends on: ii libapparmor1 2.8.0-5+b1 ii libc6 2.18-4 ii libcap2 1:2.22-1.2 ii multiarch-support 2.18-4 Versions of packages lxc recommends: ii debootstrap 1.0.59 ii libcap2-bin 1:2.22-1.2 lxc suggests no packages. -- no debconf information
Bug#679275: debian-installer: Debian installer fails when defining 10 or more partitions
Package: debian-installer Severity: minor Dear Maintainer, the debian installer will fail to install the system with 10 or more partitions defined during the manual partitioning process. This is due to the fact that the hard coded regexp for finding the first partition in the system will fail to return a single line, e.g. [hs]da1 will return sda1\n sda10 After that the installation process will terminate itself and the system will not boot, since neither grub nor a proper boot partition have been initialized. This is a bug that is not only present in debian but also most of its derivates. Regards, Carsten *** Please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these lines *** -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679276: debian-installer: Debian installer fails to prevent the user from defining more than 10 md devices
Package: debian-installer Severity: minor Dear Maintainer, the debian installer will fail to prevent the user from defining more than 10 raid md devices. I reckon that there is a hard limit for the maximum number of md devices, yet the installer will happily continue with letting the user define more than what is permitted by the hard coded limit. In the end, this will lead to a painful lessons learned, as the user will have to redo alls of his partitioning scheme, and, considering that the same user created multiple software raids of various levels, and, subsequently also, multiple volume groups, the learning process has been very painful. It would be great if the installer would detect and prevent the erroneous situation. This is a bug that is not only present in debian but also most of its derivates. Regards, Carsten *** Please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these lines *** -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
