Bug#606094: Intend to Add

2010-12-06 Thread Michael Lustfield
severity normal
tags 606094 + patch
stop

The patch certainly seems simple and easy enough. I'll review this in
more detail tomorrow.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#608987: oops

2011-01-05 Thread Michael Lustfield
I'm sorry... I spaced pretty bad. I was thinking unstably was squeeze. The
issue was fixed in unstable, but has not yet made its way back to squeeze. That
is what I meant about the backport.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#610290: Solution

2011-01-20 Thread Michael Lustfield
I thought about this long and hard. It seems that the best route to keep this
from being an issue when switching between -full,-light,-extras is a separate
package for those files (nginx-common). Rather than using nginx-common and
dealing with the exact same bug (here, not later) I figured we could just use
the existing nginx dummy package for the common files.

I just committed the changes required for this to the svn repo. It will no
doubt need testing. I will set up a vm tonight to play with the package
upgrades to ensure they roll out smoothly.

Thanks again for taking the time to both file and elaborate on this issue.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#609343: Added the Patch

2011-01-20 Thread Michael Lustfield
I committed the patch to the svn repo today. If you have the chance and are
comfortable with it, could you test it to make sure I didn't make any mistakes?

http://svn.debian.org/viewsvn/collab-maint/deb-maint/nginx/trunk/debian/patches/609343-log-time-iso8601.diff?view=log

Thanks for taking the time to file and explain this bug.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#609797: Thanks

2011-01-20 Thread Michael Lustfield
As part of another bug, I reworked the package/files structure a bit as well
as debian/rules. This bug should be resolved with the next release of the
nginx package.

Thanks for taking the time to let us know about this issue. I know you consider
this 'picky' but I do enjoy pedantic reviews. I like to know that the work
going into Debian is 100% perfect. :D



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#608983: Found the Problem

2011-01-20 Thread Michael Lustfield
I found what is causing this. The following is happening because of an unpurged
package. The configs are left behind (even after 'aptitude remove'). Using
aptitude purge on all nginx packages and then reinstalling should be enough to
resolve this.

 /etc/cron.daily/logrotate:
 error: nginx-light:1 duplicate log entry for /var/log/nginx/access.log
 error: found error in /var/log/nginx/*.log , skipping

You can use this following command to purge packages that were removed.

 aptitude --purge-unused purge ~c

I 'think' that this issue might be resolved by bug #610290.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#610854: nginx-light: Use /var/www instead of /usr/share/nginx/www

2011-01-23 Thread Michael Lustfield
Just because there's an 'exception' doesn't mean it's ok to do it.
This exception is in
place because, in the past, it was the 'de facto' place to put web
content. Because
of how packages work, it's no longer normal to place content in this location.

It is a policy violation because /var/www is not part of the standard
Linux directory
hierarchy. There is no need to violate this policy and use a lintian
override as you
suggested because how things are done now is the proper way to do it.

For the above reasons, we have no intention of changing the default behavior. If
you still feel this is in error, please explain why you feel it is so
important that we
place Nginx files at this location.

Thanks,
Michael Lustfield



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#610983: Correct Permissions

2011-01-25 Thread Michael Lustfield
root@liber:~# ls -ld /var/log/nginx/
drwxr-xr-x 2 root root 4096 2011-01-25 06:25 /var/log/nginx/

root@liber:~# ls -l /var/log/nginx/*.log
total 6860
-rw-r- 1 www-data adm  1159268 2011-01-25 15:12 access.log
-rw-r- 1 www-data adm  652 2011-01-25 11:01 error.log
-rw-r- 1 www-data adm   356272 2011-01-25 15:12 usage.log


The above shows the directory as world readable meaning the user can look
inside the directory. However, the contents within are not.

I will double check that these permissions are what's being assigned. If this
is the case, then there is nothing wrong in the packaging. The above
permissions are what is expected after installing the package.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#610983: I see it

2011-01-25 Thread Michael Lustfield
Alrighty... I can see the issue now. I need to run off, but I'll have this
resolved before the next nginx package is released. Thanks.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#612832: nginx-common: Nginx won't reopen log files.

2011-02-10 Thread Michael Lustfield
Package: nginx-common
Version: 0.8.54-3
Severity: important

Recently I noticed that logrotate does not actually rotate the files correctly.
I noticed this in 0.8.54-3 and is an issue in what will be 0.8.54-4. 

The issue seems to be that neither -USR1 or -s reopen will reopen the log files
after they've been rotated. I'm not sure if this specific to the version
packaged in Debian but I've seen it as an issue on both Ubuntu and Debian.

Below is what I tried to do to figure out what's going on...

### Clean slate
root@liber:/var/log/nginx# /etc/init.d/nginx stop
Stopping nginx: nginx.
root@liber:/var/log/nginx# rm *

### Start Nginx: Creates new log files
root@liber:/var/log/nginx# /etc/init.d/nginx start
Starting nginx: nginx.
root@liber:/var/log/nginx# du access.log access.log.1
8   access.log
du: cannot access `access.log.1': No such file or directory

### Force logrotate to run (which runs the kill -USR1)
root@liber:/var/log/nginx# logrotate -f /etc/logrotate.d/nginx 

### Log files rotated
root@liber:/var/log/nginx# du access.log access.log.1
0   access.log
8   access.log.1

### At this point files should already be getting written to the new file
### because of the -USR1 in the logrotate script
root@liber:/var/log/nginx# du access.log access.log.1
0   access.log
24  access.log.1

### To make sure the kill was run, we invoke it ourselves
root@liber:/var/log/nginx# kill -USR1 `cat /var/run/nginx.pid`

### And see that nginx still isn't using the new file
root@liber:/var/log/nginx# du access.log access.log.1
0   access.log
48  access.log.1

### Using the more proper approach
root@liber:/var/log/nginx# nginx -s reopen

### We get the same thing
root@liber:/var/log/nginx# du access.log access.log.1
0   access.log
68  access.log.1

### Trying a less appropriate option
root@liber:/var/log/nginx# /etc/init.d/nginx reload
Reloading nginx configuration: nginx.

### It's finally reopened the files
root@liber:/var/log/nginx# du access.log access.log.1
20  access.log
68  access.log.1



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#612832: Alrighty...

2011-02-12 Thread Michael Lustfield
I see what's going on here. This is partially a result of incorrectly fixing a
bug about permissions.

The file system permissions should be similar to this...
drwxr-xr-x 8 root root   4096 2011-02-11 06:46 /var/log
drwxr-xr-x 2 root root   4096 2011-02-12 02:46 /var/log/nginx
-rw-r- 1 root adm   0 2011-02-12 02:46 /var/log/nginx/access.log
-rw-r- 1 root adm 1533983 2011-02-12 03:24 /var/log/nginx/access.log.1
-rw-r- 1 root adm  61 2011-02-12 02:48 /var/log/nginx/error.log
-rw-r- 1 root adm  108957 2011-02-12 03:21 /var/log/nginx/error.log.1
-rw-r- 1 root adm   0 2011-02-12 02:46 /var/log/nginx/usage.log
-rw-r- 1 root adm  435252 2011-02-12 03:24 /var/log/nginx/usage.log.1

What we have is this:
drwxr-xr-x 8 root root4096 2011-02-11 06:46 /var/log
drwxr-x--- 2 root root4096 2011-02-12 02:46 /var/log/nginx
-rw-r- 1 www-data adm0 2011-02-12 02:46 /var/log/nginx/access.log
-rw-r--r-- 1 root root 1533983 2011-02-12 03:24 /var/log/nginx/access.log.1
-rw-r- 1 www-data adm   61 2011-02-12 02:48 /var/log/nginx/error.log
-rw-r--r-- 1 root root  108957 2011-02-12 03:21 /var/log/nginx/error.log.1
-rw-r- 1 www-data adm0 2011-02-12 02:46 /var/log/nginx/usage.log
-rw-r--r-- 1 root root  435252 2011-02-12 03:24 /var/log/nginx/usage.log.1

The logrotate file has this:
  create 640 root adm
Which means that any recreated files should be root:adm instead of www-data:adm.

Somehow, these are being created incorrectly. I also notice that initial files
created by Nginx itself are 644 rather than 640. However, I don't believe this
is behavior we can change. Once logrotate runs once, all new files are created
correctly. We could possible add empty files to begin with.

Anyway... this issue is why nginx is not able to reopen the newly created fiels
and continues to write to the old files.

I'll begin working on a proper solution for this tomorrow.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#567377: Changing RFP to ITP and package name

2011-02-25 Thread Michael Lustfield
retitle 567377 ITP: tdc -- Tiny Dockable Clock (tdc) is a simple and tiny 
dockable clock.
owner 567377 !
thanks

Because of upstream issues, I've decided to fork this project and actually
expanded on it quite significantly. This package is nearly uploaded and ready
for a sponsor.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#607418: Interesting Patch

2010-12-24 Thread Michael Lustfield
I was just looking over the patch. It seems like a perfectly acceptable patch
in that it would result in the desired output every time. However, I'd like to
look at this a little further to see if this is the best approach. I'll look
over this more closely after my 'Christmas Marathon.'

I also noticed this is an issue with every version of Nginx. I mentioned this
to another Nginx developer as well as Igor.

Thanks again for this patch.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#608983: (no subject)

2011-01-19 Thread Michael Lustfield
I'm not so sure why this was cloned to nginx-full considering it's an issue
with all the nginx variants packaged...

I'm looking into this to figure out what's causing the issue. I'll get it fixed
as soon as I can figure out the issue.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#609797: Documentation placed under wrong directory

2011-01-19 Thread Michael Lustfield
severity minor
stop

Thanks for making us aware of the issue. I guess my intention was to omit
the /usr/share/doc/nginx-{full,light,extras} directories altogether. I should
have this resolved within the next few days.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#610290: nginx isn't upgraded properly

2011-01-19 Thread Michael Lustfield
I'm sorry, this makes MUCH more sense. I messed up my back pretty bad today...
I'm going to blame this one on the pain meds.

It's true that this is not expected behavior because this is a conf file. This
is happening because nginx was replaced by nginx-full.

The issue is not in the nginx-full package as the file is listed
in /var/lib/dpkg/info/nginx-full.conffiles.

I'm not really sure how to deal with this in a package transition. It'll
probably have to be a hack in postinst but I'm not entirely sure this is even
possible.


signature.asc
Description: PGP signature


Bug#567377: ITP: lal -- Lal is a clock for the dock. Nothing more, nothing less.

2010-01-28 Thread Michael Lustfield
Package: wnpp
Severity: wishlist
Owner: Michael Lustfield mtecknol...@ubuntu.com

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


* Package name: lal
  Version : 1.1
  Upstream Author : Dave Foster d...@minuslab.net
* URL : http://projects.l3ib.org/lal
* License : GPL
  Programming Lang: C
  Description : Lal is a clock for the dock. Nothing more, nothing less.

 Lal is a clock for the dock. Nothing more, nothing less. It is a very
 simple tool especially helpful for those that are using openbox. It
 can use various colors, sizes, formats, etc. It can accept any POSIX
 date format.
 .
 Window managers that are reported to work well with lal:
  - FVWM
  - OpenBox
  - Enlightenment
  - ion3


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

iEYEARECAAYFAkth3t0ACgkQ3y7Nst6YLGUwkQCgj4EjmTlVPMky0KhxY3xhfwAb
R+cAoJNGsrXYWov6i8Eh1MwMwQ3mkvUY
=p3mD
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#567377: ITP: lal -- Lal is a clock for the dock. Nothing more, nothing less.

2010-01-28 Thread Michael Lustfield
dockable clock applet for various window managers

I asked the developer of this and he said that this sounds good. Thanks
for the recommendation.

On Fri, 29 Jan 2010 10:19:40 +1100
Ben Finney ben+deb...@benfinney.id.au wrote:

 (Remember to keep the bug report in Cc on your messages if you want
 them included in the report.)
 
 On 28-Jan-2010, Michael Lustfield wrote:
  Ben Finney ben+deb...@benfinney.id.au wrote:
   Do you need to qualify the window manager with “light weight”? I
   get the impression that it should work in any window manager that
   supports docking.
   
   Is the term “applet” applicable? How about:
   
   dockable clock applet for various window managers
  
  It also works in window managers that don't support the dock.
 
 Okay, then I would recommend not mentioning “dock” in the synopsis.
 
  I just wanted to emphasize light weight somewhere because the code
  base is VERY small. The code is only ~300 lines long iirc.
 
 What about:
 
 low-footprint clock applet for various window managers
 
 An alternatives to “low-footprint” might be “low-resource”.
 


-- 
Michael Lustfield
Kalliki Software

Network and Systems Administrator


signature.asc
Description: PGP signature


Bug#567377: ITP: lal -- Lal is a clock for the dock. Nothing more, nothing less.

2010-01-30 Thread Michael Lustfield
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I made the requested change. Unless there are further change requests I
will push this package to mentors.debian.org and put in an RFS.

Thanks for the input Ben,
- -- 
Michael Lustfield
Kalliki Software

Network and Systems Administrator
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAktlCTIACgkQ3y7Nst6YLGV00ACfTlTrMzlF8dXMY85RIa4SgM2G
QCwAnjGxQVwc03x0MITh26zOlLgVLDmn
=Lhzq
-END PGP SIGNATURE-


Bug#574913: ITP: lal -- dockable clock applet for various window managers

2010-03-21 Thread Michael Lustfield
Package: wnpp
Severity: wishlist
Owner: Michael Lustfield mtecknol...@ubuntu.com

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


* Package name: lal
  Version : 2.0-1
  Upstream Author : Mikael Magnusson mika...@comhem.se
  : Dave Foster d...@minuslab.net
  : Thayer Williams tha...@archlinux.org
* URL : http://projects.l3ib.org/lal/
* License : GPL
  Programming Lang: C
  Description : dockable clock applet for various window managers

Description: dockable clock applet for various window managers
 Lal is a clock for the dock. Nothing more, nothing less. It is a very
 simple tool especially helpful for those that are using openbox. It
 can use various colors, sizes, formats, etc. It can accept any POSIX
 date format.


Note: Version 1.1 is currently sitting in the upload queue. I am hoping
to finish version 2.0 within a few months that will come with many new
features such as a calendar. One goal of the new version will be to check
through the code to see if this tiny file can be stripped down at all to
make it even more light weight.
I'm working with the upstream authors to bring this release which is why
I refer to anticipated features for this version.

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

iEYEARECAAYFAkum0ZoACgkQ3y7Nst6YLGX9tACggPO7tHb1OCPmBCWu98sc0j+K
lDYAn0Klh5YnSuQg6K9M6MVp5chydLXg
=Y0kR
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#578029: Already Running?

2010-11-28 Thread Michael Lustfield
The message [emerg]: bind() to [::]:80 failed (98: Address already in use)
happens when you try to start Nginx and it is already running. Would this
happen to be the case?

Could you please check that it is not running with ps?

Thanks,
Michael Lustfield



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#593580: I'll look into this

2010-11-28 Thread Michael Lustfield
owner 593580 mtecknol...@debian.org
stop

I'll look into adding either this script or one similar.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#605529: nginx: Default worker_connections too high for default system

2010-11-30 Thread Michael Lustfield
Package: nginx
Severity: minor

For Debian systems, the default file descriptor limit is 1024. The
default configuration has worker_connections 1024. These worker
connections use up a file descriptor for each connection.

Because file descriptors are also used for stdin, stderr, stdout, and
log files this number causes issues when the connections get to be too
high.

For this reason, the worker_connections limit should be moved to 768 to
allow ample room for connections.

This will eliminate errors such as:
  accept() failed (24: Too many open files)

Instead, when the connections limit is reached, there will be the error:
  [alert] 17831#0: 2 worker_connections are not enough

This will leave the administrator to finish configuring the system to
handle higher loads based on a more descriptive error message. The limit
will also be coming from Nginx limits rather than system limits.

-- System Information:
Debian Release: squeeze/sid
  APT prefers natty-updates
  APT policy: (500, 'natty-updates'), (500, 'natty-security'), (500, 'natty')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.36 (PREEMPT)
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 nginx depends on:
ii  libc62.12.1-0ubuntu9 Embedded GNU C Library: Shared lib
ii  libgeoip11.4.7~beta6+dfsg-1  A non-DNS IP-to-country resolver l
ii  libpcre3 8.02-1.1Perl 5 Compatible Regular Expressi
ii  libssl0.9.8  0.9.8o-3ubuntu1 SSL shared libraries
ii  lsb-base 4.0-0ubuntu8Linux Standard Base 4.0 init scrip
ii  zlib1g   1:1.2.3.4.dfsg-3ubuntu1 compression library - runtime

nginx recommends no packages.

Versions of packages nginx suggests:
ii  ufw   0.30.0-2   program for managing a Netfilter f



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#594438: Please Review

2010-11-30 Thread Michael Lustfield
Could you please review this issue against Nginx 0.8.53-1 and verify that it
has been addressed?



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#622268: Wishlist nginx 0.8.54-4

2011-04-11 Thread Michael Lustfield
Could you please provide justification for this addition as well as an
expected number of users that would benefit from this addition? From my
reading it would be a module that would be very seldom used and I would
somewhat like to limit low use modules in order to reduce packaging work and
overhead.


Bug#622706: PHP5-FPM depends on /var/www

2011-04-13 Thread Michael Lustfield
Package: php5-fpm
Version: 5.3.6-8

The php5-fpm package depends on /var/www but does not supply this directory
itself. Instead, it relies on other packages to have already created this
directory for it and does not depend on any of them.

Two options:
1) Stop depending on /var/www
   http://lintian.debian.org/tags/dir-or-file-in-var-www.html
2) Provide /var/www
   /debian/php5-fpm.dirs

Personally, I believe option 1 is significantly better.

Either way, the way it is now, if /var/www hasn't been created by the user or
another application, the installation will throw an error and php5-fpm will be
unable to start.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#621882: nginx: FTBFS on kfreebsd-*: ./configure failure?

2011-04-15 Thread Michael Lustfield
hmm... that's interesting... Must be one of the differences between
-light and -full then. When I get home I'll try to make a vm and play
around with it until i get it building and see if I can pinpoint where
it's breaking.

On Fri, Apr 15, 2011 at 1:57 AM, Kartik Mistry kartik.mis...@gmail.com wrote:
 On Sun, Apr 10, 2011 at 3:09 AM, Cyril Brulebois k...@debian.org wrote:
 your package no longer builds on kfreebsd-*; not exactly sure why, the
 log isn't very verbose:
 ...
 Full build logs:
  https://buildd.debian.org/status/package.php?p=nginx

 I reproduced it in kfreebsd-amd64 vm. My log is bit different here:
 
 
 --add-module=/tmp/buildd/nginx-1.0.0/debian/modules/nginx-echo \
 --add-module=/tmp/buildd/nginx-1.0.0/debian/modules/nginx-upstream-fair \
config.status.full
 auto/init: 39: cannot create /dev/null: Permission denied
 ./configure: 43: cannot create /dev/null: Permission denied
 ./configure: 43: cannot create /dev/null: Permission denied
 ./configure: 43: cannot create /dev/null: Permission denied
 auto/feature: 119: cannot create /dev/null: Permission denied
 make: *** [config.status.full] Error 1
 dpkg-buildpackage: error: debian/rules build gave error exit status 2

 --
 Kartik Mistry
 Debian GNU/Linux Developer
 IRC: kart_ | Identica: @kartikm







-- 
Michael Lustfield

Kalliki Software, SD LoCo
Network and Systems Administrator



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#621882: File AIO

2011-04-15 Thread Michael Lustfield
A previous bug [1] requested that we add file aio support to Nginx. This was a
decision that we were unsure about but decided to do for nginx-extras as
somewhat of a test and left it because it did not cause issues.

Ian Carpenter has been hard at work and it seems that the --with-file-aio
option is causing issues with building on maemo. Given other information, I
feel that these two issues may be directly related.

If this is the case, we should remove --with-file-aio from nginx-extras. This
will definitely need to be tested to be sure these bugs are the same and this
solution both works and does not produce additional issues.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613175



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#618306: Add Info

2011-03-14 Thread Michael Lustfield
Could you please add 1) information about why you feel these modules should be
included and 2) where the most up to date source is supplied (preferably a
version controlled option? Thanks.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#618306: More Info

2011-03-21 Thread Michael Lustfield
tags 618306 + moreinfo
stop



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#624280: php5-fpm depends on a directory that it doesn't supply

2011-04-26 Thread Michael Lustfield
Package: php5-fpm
Severity: important


PHP5-FPM has a default pool for www that is also enabled by default. It depends 
on /var/www existing. However, it does not provide this directory which it 
depends on. If someone has not created this directory or another package has 
not created it for them, this will cause php5-fpm to output errors and be 
unable to start after installing.

This package could either provide the directory (/var/www) that it is depending 
on or it could instead not depend on that directory. According to Debian policy 
[1], this directory should not be used by packages anyway so the better 
solution would be to not depend on the directory.

[1] http://lintian.debian.org/tags/dir-or-file-in-var-www.html

-- System Information:
Debian Release: squeeze/sid
  APT prefers natty-updates
  APT policy: (500, 'natty-updates'), (500, 'natty-security'), (500, 
'natty-backports'), (500, 'natty')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.38-7-server (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
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#619482: Provide More Details

2011-05-07 Thread Michael Lustfield
This is an easy fix. However, 0.7.67 is only in Debian stable. Could you please
provide details about what effect this has so we can see if it justifies an
update to stable?



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#613175: Added

2011-02-15 Thread Michael Lustfield
I added file aio support to nginx-extras in 0.8.54-4. The reason this is not in
the default nginx (nginx-full) is because it's usually a bad idea to use. In
the vast majority of cases, it will cause degradation in performance. Being
enabled also alters behaviors such as epoll usage. To disable you actually have
to fall back to select.

In addition, by compiling Nginx with AIO support, it can not be fully disabled.
Even if not enabled vio the config, having the support compiled into Nginx will
still alter behavior.

In BSD it would have better performance benefits where it can be coupled with
send-file but in the case of Linux, we usually get better performance by using
the file system caching which is bypassed by enabling AIO.

That of course isn't the case for every situation, but for most cases it is.

Anyway... It's added and committed for nginx-extras and will be there for the
next nginx release. Enjoy.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#610289: Just FYI

2011-02-15 Thread Michael Lustfield
Just as an FYI... I believe I have resolved this bug; but I have to test it to
be completely sure. That could potentially take me a little while.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#613355: Thanks

2011-02-15 Thread Michael Lustfield
Thanks for catching this. I have also made a redirect in the wiki so this is
not an issue while we wait for the fix to be released.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#610983: Nope

2011-02-15 Thread Michael Lustfield
I thought I fixed this bug in my testing package. It turns out that I actually
caused more issue. As a result, bug #612832 [1] now exists. I'll resolve these
both at the same time.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612832



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#567377: lal: changing back from ITP to RFP

2011-02-19 Thread Michael Lustfield
Thanks, I keep forgetting about this package. I've been working on Nginx
packaging so I should be in a good place for doing this pretty soon. I'll
reclaim it then. :)

On Sat, 19 Feb 2011 17:07:20 +
Lucas Nussbaum lu...@debian.org wrote:

 retitle 567377 RFP: lal -- Lal is a clock for the dock. Nothing more, nothing
 less. noowner 567377
 thanks
 
 Hi,
 
 This is an automatic email to change the status of lal back from ITP
 (Intent to Package) to RFP (Request for Package), because this bug hasn't seen
 any activity during the last 6 months.
 
 If you are still interested in adopting lal, please send a mail to
 cont...@bugs.debian.org with:
 
  retitle 567377 ITP: lal -- Lal is a clock for the dock. Nothing more,
 nothing less. owner 567377 !
  thanks
 
 However, it is not recommended to keep ITP for a long time without acting on
 the package, as it might cause other prospective maintainers to refrain from
 packaging that software. It is also a good idea to document your progress on
 this ITP from time to time, by mailing 567...@bugs.debian.org.
 
 Thank you for your interest in Debian,



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#636597: Info

2011-08-08 Thread Michael Lustfield
Any chance you could provide a justification of why this third party module
should be built into every version of nginx? It seems like added overhead that
is not needed for nginx-full and definitely not nginx-light. I could see it in
nginx-extras, but we would need a good reason before adding yet another third
party module to the package. Remember- we have to keep these modules up to date
as well as the nginx source.

Pretty much- just looking for a good and strong justification.
(not- this is what's keeping nginx from the big-time, today)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#664850: (no subject)

2012-06-18 Thread Michael Lustfield
While it's true that the wiki suffered a lot of down time in the past, it's now
been moved to some redundant servers. Uptime should be less of a concern in the
future. 6.0MB of compressed data seems like an awful lot of data to expand and
organize and maintain. I can't think of any sane way to do this.

-- 
Michael Lustfield
Ubuntu Member, Nginx Developer



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org




Bug#688410: (no subject)

2012-10-29 Thread Michael Lustfield
tags 688410 - unreproducible
thanks

It's definitely an edge case that this would ever crop up. It's a pretty safe
sanity check that only takes a few extra clock cycles during the installation.

I do have to wonder, however, if that symlink should not be moved to
nginx-common.postinstall...

I have a feeling that we'll end up doing this which should eliminate that
potential issue entirely.

-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#660408: Late Here

2012-02-24 Thread Michael Lustfield
Boy oh boy am I late to the party!

I do agree that this is a good feature to have. I've been sold on the Auth PAM
module as it seems to be rather stable and also seems to be the most flexible.
It seems that Cyril also agrees that this is a good feature to have.

However, I do not feel comfortable putting it in anything other than
nginx-extras. I have included in there. Unless I see some very good and
compelling reason to include it in -light or -full, it'll stay there only.

-- 
Michael Lustfield
Ubuntu Member, Nginx Developer



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#657852: Been Unstable

2012-02-06 Thread Michael Lustfield
In my experience, the fancyindex module has been extremely unstable and prone
to breaking. As much as I'd love to be able to use it myself, I'd like to see a
lot of testing done before considering it for inclusion.

-- 
Michael Lustfield
Ubuntu Member, Nginx Developer



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#668953: lists.debian.org: please create debian-nginx

2012-04-15 Thread Michael Lustfield
Package: lists.debian.org
Severity: wishlist


Here is the requested information as per [2].

Name:
  debian-nginx

Rationale:
The current Nginx package maintainers have been involved in an
increasing number of conversations related to web server packages
and would like a list that would let us communicate in a single
place and make public our previous discussions.

Short description:
Maintaining the Debian Nginx (web server) and related packages

Long Description:
Maintenance of the Nginx HTTP server and related packages in
Debian: code changes, reproducing bugs, talking to upstream etc.

This list is not for submitting bug reports or support requests.

Category:
Developers

Subscription Policy:
Open

Post Policy:
Open

Web Archive
Yes



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#651441: Potential Headache

2012-03-29 Thread Michael Lustfield
I would like to very strongly discourage the inclusion of a passenger
module. No offense to passenger, but in terms of Nginx it tends to
cause a massive number of headaches. In general, the Nginx community
not only won't support the use of passenger, but also will offer no
support when it's involved. I would recommend not adding support for
passenger. If doing so then a separate package is definitely the way
to go, but it's very likely that it will become a support headache.

18:15  ngxbot Passenger is neither supported nor endorsed by the
community, please don't ask about it. Ideally, please don't use it.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#705401: Include ability to load dynamic modules

2013-04-14 Thread Michael Lustfield
tags +wontfix
thanks

We won't be applying any patches to make this work. Nginx will be making this
available in the future. When they add that functionality, we'll make the
packages work with it.

-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#705401: (no subject)

2013-04-14 Thread Michael Lustfield
tags 705401 + wontfix

forgot the bug number...


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#697940: (no subject)

2013-04-15 Thread Michael Lustfield
tags 697940 + wontfix
thanks


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#695119: (no subject)

2013-04-15 Thread Michael Lustfield
I'm not entirely sure what we're expected to do here. I'm not able to reproduce
the issue as described.

-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#700857: IRC

2013-04-15 Thread Michael Lustfield
Instead of trying to debug this config issue in a bug report thread, could you
join #nginx on irc.freenode.net? We can work through your issue there and then
just summarize the resolution here.

-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#696797: (no subject)

2013-04-15 Thread Michael Lustfield
I'm still not able to reproduce this behavior.

-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#652108: Some news about these scripts

2012-12-19 Thread Michael Lustfield
Further Development...

I plan to completely rewrite the logic in these scripts. I guess this would
be the third full rewrite. I will try to get to them today or tomorrow.

We discussed in the past whether this should be part of nginx-common or if
there should be an nginx-utils package added for this. I'm not sure. We're
getting a lot of nginx-* packages but the -utils package makes sense.

Any opinions?


On Wed, Dec 19, 2012 at 2:58 PM, Cyril Lavier
cyril.lav...@davromaniak.euwrote:

 Hello.

 First, thanks Thomas for relaying the bug in Ubuntu. I will try to
 update both bugs when giving updates.

 The project is still alive (here :
 https://github.com/davromaniak/nginx_ensite). First, we wanted to add
 them before the freeze of debian wheezy, but we thought the scripts
 where too green for that and we delayed their inclusion.

 We schedule to include the scripts for Wheezy+1, and after the freeze of
 Ubuntu Raring, as we don't want to risk adding severe bugs in a stable
 (even not LTS) release of Ubuntu.

 By the way, if anybody wants to grab the script and test it, don't
 hesitate to do so and open issues on github if needed.

 Thanks.

 --
 Cyril Davromaniak Lavier
 KeyID 59E9A881
 http://www.davromaniak.eu




Bug#652108: Some news about these scripts

2012-12-20 Thread Michael Lustfield
Yup, that's true. So we'll keep it in -common! :)  I still need to find the
time to rework them to make them as sensible as possible.


On Wed, Dec 19, 2012 at 11:50 PM, Ondřej Surý ond...@sury.org wrote:

 nginx-utils would only make sense in case the package would be Arch: any
 while nginx-common is Arch: all.

 And I guess the en/dis scripts are in a scripting language, right?

 Ondřej Surý

 On 20. 12. 2012, at 1:29, Thomas Ward trekcaptainusa...@ubuntu.com
 wrote:

  I think the point of consideration for splitting into another package is
 this: For just these two scripts (one to enable a site, one to disable), do
 we really need to split them off into their own package, and add that as a
 dependency for all the versions of nginx, when we already have each version
 (-light, -full, -extra, etc.) depending on nginx-common?
 
  I think splitting these off into their own package (the proposed -utils
 package) is only a good idea if more utilities are planned in the future.
  Otherwise, since the two scripts are going to be used for all versions of
 nginx (-light, -full, -extra, etc.), and if there's no plans for future
 utility scripts, then these should just be considered common, and put in
 nginx-common.
 
  --
  Thomas



Bug#697940: Status

2013-03-11 Thread Michael Lustfield
nginx maintainers, what's the status?

... Look at the link to the root bug. There's a reason they haven't taken that
patch and committed it yet. This isn't trivial and we're not going to decide
how this non-issue should be rectified. Us making a small change could cause
a big headache down the road. Patience.

Honestly... If you don't trust the network in which proxy_pass is being sent to
or the network in between, you're already screwed. I don't even see a
legitimate need for proxy_pass to https backends.

Trusting Trust


* This issue will be closed when upstream closes it. We won't be doing any
special patching for this bug without careful consideration.

-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#701112: (no subject)

2013-03-11 Thread Michael Lustfield
In debian/nginx-common.postinst we have:

  configure)
logdir=/var/log/nginx
# Ensure existance and right state of log files and directory
if [ ! -d $logdir -a ! -L $logdir ]; then
  mkdir $logdir
  chown www-data:adm $logdir
  chmod 0750 $logdir
fi

This should create the log directory if it doesn't already exist. We're not
enforcing this because the permissions could be changed. Is there any better
way to handle this than what we're doing now? I haven't tested, but it seems
that this should work. I'm sure I'm missing something...

-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#696797: (no subject)

2013-03-11 Thread Michael Lustfield
I haven't been able to reproduce this. Does it happen after an update or just
out of the blue? We need more information to track it down.

-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#701112: (no subject)

2013-03-12 Thread Michael Lustfield
precautionary - That would mean we assume that making the change won't
break anything. We're setting this for new installs but forcing it on
already deployed systems wouldn't be a good idea. We could add a NEWS entry
to recommend making this change. It's definitely not a good idea to force
it to happen.


On Tue, Mar 12, 2013 at 7:53 AM, Steven Chamberlain ste...@pyro.eu.orgwrote:

 Hi,

 On 12/03/13 03:33, Michael Lustfield wrote:
  In debian/nginx-common.postinst we have:
 
configure)
  logdir=/var/log/nginx
  # Ensure existance and right state of log files and directory
  if [ ! -d $logdir -a ! -L $logdir ]; then
mkdir $logdir
chown www-data:adm $logdir
chmod 0750 $logdir
  fi

  This should create the log directory if it doesn't already exist. We're
 not
  enforcing this because the permissions could be changed. Is there any
 better
  way to handle this than what we're doing now? I haven't tested, but it
 seems
  that this should work. I'm sure I'm missing something...

 Else if it already exists as a directory, and are upgrading from package
 version 1.2.1-2.2 or earlier, do a precautionary `chmod o-rx`?

 If ownership is still 'root:root', should chown to 'www-data:adm' so
 that log parsers retain access.  Maybe a NEWS entry could advise about
 adding things into that group if they don't run as root or www-data but
 still need to be able to read the nginx logs?


 Some test cases I can think of are:

 * no log parsers in use - chmod o-rx is the important thing to do

 * logwatch - runs as root?  changing the ownership/perms doesn't matter

 * awstats - the log parser part (update.sh) runs as user www-data

 * other CGI/PHP apps running as user www-data

 * other CGI/PHP apps running under separate uids - should be added to a
 group that has read access.  If the admin already changed the user or
 group of /var/log/nginx, respect that, otherwise chgrp to adm and
 suggest they add their log parsers into that group if necessary.  The
 alternative would be to just keep wide-open access...


 Wide-open HTTP logs could be a breach of privacy, reveals usernames for
 HTTP authentication, IP addresses of visitors, search queries or other
 HTML form input with a GET action, locations of potentially sensitive
 documents that would be otherwise impractical to guess, and provides a
 catalogue of installed web apps that would likely assist an attacker if
 this were some kind of shared host with other users.

 Thanks,
 Regards,
 --
 Steven Chamberlain
 ste...@pyro.eu.org



Bug#700857: [#ZIH-894-30161]: Re: Bug#700857: postinst stops nginx instead of restarting it

2013-02-18 Thread Michael Lustfield
Get rid of /etc/nginx/sites-enabled/000-default.


On Mon, Feb 18, 2013 at 10:28 AM, Martin von Wittich i...@iserv.eu wrote:

 Hi Steven,

  That looks like it tried to restart, but may have failed for some
  reason. You may want to check /var/log/nginx/error.log for clues...

 The error.log.1 file says:

 2013/02/18 04:02:37 [emerg] 28203#0: bind() to [::]:80 failed (98: Address
 already in use)
 [emerg]: bind() to [::]:80 failed (98: Address already in use)
 2013/02/18 04:02:37 [emerg] 28203#0: bind() to [::]:80 failed (98: Address
 already in use)
 [emerg]: bind() to [::]:80 failed (98: Address already in use)
 2013/02/18 04:02:37 [emerg] 28203#0: bind() to [::]:80 failed (98: Address
 already in use)
 [emerg]: bind() to [::]:80 failed (98: Address already in use)
 2013/02/18 04:02:37 [emerg] 28203#0: bind() to [::]:80 failed (98: Address
 already in use)
 [emerg]: bind() to [::]:80 failed (98: Address already in use)
 2013/02/18 04:02:37 [emerg] 28203#0: bind() to [::]:80 failed (98: Address
 already in use)
 [emerg]: bind() to [::]:80 failed (98: Address already in use)
 2013/02/18 04:02:37 [emerg] 28203#0: still could not bind()
 [emerg]: still could not bind()

 That correlates with the update. There shouldn't be anything else besides
 nginx that binds to port 80 though, so I'm not sure what could have caused
 this.


 --
 Mit freundlichen Grüßen,
 Martin von Wittich

 IServ GmbH
 Bültenweg 73
 38106 Braunschweig

 Telefon:   0531-2243666-0
 Fax:   0531-2243666-9
 E-Mail:i...@iserv.eu
 Internet:  iserv.eu

 USt-IdNr. DE265149425 | Amtsgericht Braunschweig | HRB 201822
 Geschäftsführer: Jörg Ludwig




Bug#728015: [nginx] Don't use type=forking in systemd service file

2013-10-27 Thread Michael Lustfield
Using 'daemon off;' in nginx will likely cause issues when a user wants to run
'nginx -s reload'. The reload signal allows nginx to not drop any connections
while bringing up a new config. This is one of the reasons that using
supervisord is disliked so much.

This is done by opening a new master process that begins taking all of the new
connections while the old master is allowed to finish handling old connections.

If we turn this off, is it possible for systemd to send nginx the reload signal
as opposed to a complete restart?

On Sun, 27 Oct 2013 17:32:48 +0100
Adrien CLERC bugs-deb...@antipoul.fr wrote:

 Package: nginx
 Version: 1.4.3-2
 Severity: minor
 
 --- Please enter the report below this line. ---
 Hi,
 
 In the systemd service file, the two following directive are used:
 Type=forking
 PIDFile=/run/nginx.pid
 
 However, when running systemd, it's easier to let systemd handle the PID 
 stuff, and tell the program not to fork itself.
 Moreover, we can have a situation when the user changes the PID file 
 location in the configuration file located at /etc/nginx/nginx.conf
 
 Thus, I recommend removing them, and disabling nginx forking with the 
 directive daemon off. See attached unit file.
 
 It is of course opened to discussion. I tried to find any side-effect of 
 daemon off, but the documentation doesn't mention any.
 
 Have fun,
 
 Adrien
 
 --- System information. ---
 Architecture: i386
 Kernel: Linux 3.11-1-686-pae
 
 Debian Release: jessie/sid
 500 unstable ftp.fr.debian.org
 1 experimental ftp.fr.debian.org
 
 --- Package information. ---
 Depends (Version) | Installed
 =-+-=
 nginx-common (= 1.4.3-2) | 1.4.3-2
 libc6 (= 2.10) | 2.17-93
 libpcre3 (= 8.10) | 1:8.31-2
 libssl1.0.0 (= 1.0.1) | 1.0.1e-3
 zlib1g (= 1:1.1.4) | 1:1.2.8.dfsg-1
 
 
 Package's Recommends field is empty.
 
 Suggests (Version) | Installed
 =-+-
 nginx-doc (= 1.4.3-2) |


-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#728038: Yessir!

2013-10-27 Thread Michael Lustfield
Yes, sir! Right away sir!
Thanks for the bug report. This has been committed. :)

-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#728103: initscript: show a proper message when test_nginx_config fails

2013-10-28 Thread Michael Lustfield
Thanks for the patch! I'll review and test it tonight, but it looks great.


On Mon, Oct 28, 2013 at 8:23 AM, Pim van den Berg 
pim.van.den.b...@mendix.com wrote:

 Package: nginx-common
 Severity: normal
 Tags: patch

 Attached is a patch to make the init script show a fail message when
 test_nginx_config fails:

 # /etc/init.d/nginx reload
 [FAIL] Reloading nginx configuration: nginx failed!

 The init script only returned a status code when testing the nginx
 configuration failed. No failure message at all. Therefor run
 test_nginx_config
 after calling log_daemon_msg.



Bug#701112: Delay...

2013-10-29 Thread Michael Lustfield
This one sure slipped under the cracks for me.

So... check if it's root:root 755;
if so, change to www-data:adm 750

Would that sufficiently deal with this?

-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#707069: Vote for no

2013-10-29 Thread Michael Lustfield
Cyril,

My vote is to not include this. The psol dependency alone should be enough to
simply say no. It's a neat module, but my opinion for this is that if others
want to use it, then they can build Nginx themselves.

The number of external libraries is also going to bloat things a lot.

I also don't see any point to it. If you write your website decent to begin
with, then this module provides nothing. This is essentially a band-aid for
people that can't write proper code to begin with. (no offense anyone...)

-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#722328: Hm..

2013-10-29 Thread Michael Lustfield
I've seen many good uses for the postgres module. I personally don't like
postgres at all. I also happen to be comfortable with that developer. However,
the two extra modules (devel kit is there) that would be required aren't
exactly light modules. It would be nice to see a bit more interest or cause
before tacking on three more modules (rds, form, postgres) to our list of
modules to manage.

-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#701508: What else?

2013-10-29 Thread Michael Lustfield
The nginx-common package is required for nginx-{light,full,extras}.
nginx-common already suggests fcgiwrap

Nginx does not provide any cgi. It will only proxy to it via fastcgi_pass.

I do not feel comfortable claiming that these packages provide this, but by
request, it's been changed and committed.

-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#697940: Closing

2013-10-29 Thread Michael Lustfield
I wasn't aware of forwarded or tags. Shows my experience level... Sorry for
prematurely closing this and thanks for giving me new stuff to learn.


On Tue, Oct 29, 2013 at 8:57 AM, Thijs Kinkhorst th...@debian.org wrote:

 reopen 697940
 forwarded 697940 http://trac.nginx.org/nginx/ticket/13
 tags 697940 = security upstream
 thanks

 Hi,

 This issue is not yet fixed in the package so it seems premature to close
 it. You're probably right that upstream needs to do this and there's no
 need for Debian to do it locally. But that is expressed with the
 'upstream' and 'forwarded' tags; no need to close it for that reason. It
 can be closed when a new upstream is uploaded to Debian that fixes the
 issue.


 Cheers,
 Thijs




Bug#718639: Seems Odd

2013-10-29 Thread Michael Lustfield
This seems like a rather odd issue. I'd like to find the best solution
possible. Could you please provide 'aptitude search nginx' output. Also,
could you please try swapping the order those directives appear. It seems
that both SCRIPT_FILENAME parameters are being passed and the first one
use. That wouldn't be intuitive... Please try flipping those and report
back the change (if any).


Bug#724756: grub-pc: Latest version of grub produces a core.img that is too large to install.

2013-12-10 Thread Michael Lustfield
On Tue, Dec 10, 2013 at 1:09 PM, Colin Watson cjwat...@debian.org wrote:

 On Tue, Dec 10, 2013 at 12:45:41PM -0600, Michael Lustfield wrote:
  On Tue, Nov 12, 2013 at 8:47 PM, Colin Watson cjwat...@debian.org
 wrote:
   Note that systems that were installed with modern versions of the
 Debian
   installer aren't affected by this bug, since that aligns the first
   partition to a 1MB boundary by default; this is actually a good idea
 for
   performance reasons too so I recommend you look into converting your
   systems to that if at all possible since this isn't an easy bug to fix
   in any other way.
 
  How can I convert an installed system to that? This image was created
 with
  a recent (at the time) Debian installer. Right now, I have to use a super
  grub2 boot disk to boot the servers.

 You have to use something like gparted from a live CD to move the
 partitions around.  This is inherently risky and requires taking backups
 first, unfortunately.

   I agree this is a real problem, though.  Could I please see the exact
   size in bytes of /boot/grub/i386-pc/core.img so that I can make sure
 I'm
   comparing the right thing?  I don't get quite the same figures as you
 in
   my local tests, and for this kind of thing every byte matters.
 
  # du /boot/grub/i386-pc/core.img
  34/boot/grub/i386-pc/core.img

 That's kilobytes, not bytes.  Try this instead:

   ls -l /boot/grub/i386-pc/core.img


Sorry, I forgot to reply to the bug too.

It's 33106 bytes.


Bug#730053: libnss-ldapd causes long login times because of recursive group lookups

2013-11-20 Thread Michael Lustfield
Package: libnss-ldapd
Version: 0.8.10-4
Severity: important

Dear Maintainer,

I have some servers that have users that log in that are members of many
groups
in an LDAP directory. When I watch debug output from nscd I see that the
user
is looked up, then the members of each group the user is a member of are
looked
up. In my case, looking up users that are members of the group that the user
logging in is a member of causes a delay of up to one minute. As far as I
can
see, this also provides no value.

Instead of pasting the entire log that I have, I'll share a link to it. This
log has been trimmed in the middle...  [...] A few hundred more of
these...


It could be possible that the culprit is actually ssh or pam, but I have
zero
clue how to debug that. If I can provide any debugging help, please, let me
know.

-- System Information:
Debian Release: 7.2
  APT prefers stable
  APT policy: (900, 'stable'), (700, 'unstable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 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 libnss-ldapd depends on:
ii  debconf [debconf-2.0]  1.5.49
ii  libc6  2.13-38
ii  multiarch-support  2.13-38
ii  nslcd  0.8.10-4

libnss-ldapd recommends no packages.

libnss-ldapd suggests no packages.

-- debconf information:
* libnss-ldapd/nsswitch: passwd, group, shadow
  libnss-ldapd/clean_nsswitch: true


Bug#730142: nginx: please provide a stronger ssl setup

2013-11-21 Thread Michael Lustfield
I definitely agree that it needs to be stronger. We'll look into this to
figure out what would likely be best. Thanks for bringing it to our
attention.


On Thu, Nov 21, 2013 at 4:12 PM, Toni Mueller supp...@oeko.net wrote:

 Package: nginx
 Version: 1.2.1-2.2+wheezy1
 Severity: normal

 Dear Maintainer,

 recently, I checked my nginx configuration with Qualy's www.ssllabs.com
 service, and found it to be not very strong. I was able to improve the
 rating by using this configuration:


 ssl_protocols   SSLv3 TLSv1 TLSv1.1 TLSv1.2;
 ssl_ciphers
 HIGH:!aNULL:!eNULL:!RC4:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:+EXP;
 ssl_prefer_server_ciphers   on;



 It would be nice if you would make this configuration the default -
 provided you agree that it configuration is stronger than the original
 configuration, and sufficiently compatible.


 Kind regards,
 --Toni++



 -- System Information:
 Debian Release: 7.2
   APT prefers stable
   APT policy: (990, 'stable'), (500, 'testing'), (100, 'unstable'), (1,
 'experimental')
 Architecture: amd64 (x86_64)
 Foreign Architectures: i386

 Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores)
 Locale: LANG=de_DE.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash

 Versions of packages nginx depends on:
 ii  nginx-full  1.4.1-3~bpo70+1

 nginx recommends no packages.

 nginx suggests no packages.

 -- no debconf information




Bug#701508: Done

2013-11-24 Thread Michael Lustfield
We added suggests fcgiwrap but not provides httpd-cgi. This has been fixed.

-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#728103: (no subject)

2013-11-24 Thread Michael Lustfield
Thanks for catching this! I'm sorry about the missing line. This has been
pushed.

-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#728015: (no subject)

2013-11-24 Thread Michael Lustfield
This has been corrected and pushed. It will be fixed in the next upload.
Thanks for taking the time and effort for this!

-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#730142: (no subject)

2013-11-24 Thread Michael Lustfield
Thanks for catching this. This has been committed and will be fixed in the next
upload. In the meanwhile, I will be doing further browser testing for
compatibility issues.

-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#718639: (no subject)

2013-11-24 Thread Michael Lustfield
I still need more information in order to be able to understand if this is an
nginx bug, a config bug, or neither. Please provide the information that was
requested.

-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#729860: (no subject)

2013-11-24 Thread Michael Lustfield
Thanks for reporting this issue. This change has been committed and will be
pushed with the next upload.

-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#722328: (no subject)

2013-11-24 Thread Michael Lustfield
I'm still waiting to see some extra level of interest. As I said, this is a
rather heavy module to add and I don't want to add it for very few users.

-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#701112: (no subject)

2013-11-24 Thread Michael Lustfield
In debian/nginx-common.preinst:

# http://bugs.debian.org/701112
if [ `stat -c '%U:%G.%a' /var/log/nginx` == 'root:root.755' ]; then
  chown root:adm /var/log/nginx
  chmod 750 /var/log/nginx
fi

This has been changed. I will create a NEWS entry and push. It will be resolved
in the next upload.

-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#730432: (no subject)

2013-11-24 Thread Michael Lustfield
This was originally added to just nginx-extras because it is not yet a stable
module. However, I've done some testing with it and feel that we can push it.
If the spdy module causes any issues, it will be taken out of nginx-full and
potentially -extras.

This will be added in the next upload. I still side with it not being needed at
all. If you build a decent web app, it offers no benefits.

-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#724756: grub-pc: Latest version of grub produces a core.img that is too large to install.

2013-09-27 Thread Michael Lustfield
Package: grub-pc
Version: 2.00-19
Severity: important

Dear Maintainer,


After upgrading to the latest version of grub-pc in Debian jessie, th core.img
file went from 32K to 36K. This makes it no longer possible to install grub to
the MBR. It seems that some of the modules are significantly larger than they
should be and this is making it impossible to install grub to what seems to be
a very common setup. The only thing extra I'm using is LVM. Adding RAID and LVM
support should still keep core.img under the 32K limit. This is an issue on
over 400 systems for me, so just moving the first partition over and doing a
--force will not be an option, nor should it be required.

Version 1.99-27+deb7u1 did not have this issue (but was close).

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/mapper/sys-root / ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
/dev/mapper/sys-boot /boot ext2 rw,relatime,errors=continue 0 0
/dev/mapper/sys-home /home ext4 rw,relatime,data=ordered 0 0
/dev/mapper/sys-opt /opt ext4 rw,relatime,data=ordered 0 0
/dev/mapper/sys-var /var ext4 rw,relatime,data=ordered 0 0
/dev/mapper/sys-varlog /var/log ext4 rw,relatime,data=ordered 0 0
/dev/mapper/homedirs-7460 /srv/homedirs/7460 ext4 rw,relatime,data=ordered 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
(hd0)   /dev/sda
(hd1)   /dev/sdb
*** END /boot/grub/device.map

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  load_env
fi
set default=0

if [ x${feature_menuentry_id} = xy ]; then
  menuentry_id_option=--id
else
  menuentry_id_option=
fi

export menuentry_id_option

if [ ${prev_saved_entry} ]; then
  set saved_entry=${prev_saved_entry}
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z ${boot_once} ]; then
saved_entry=${chosen}
save_env saved_entry
  fi
}

function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_msdos
insmod lvm
insmod ext2
set root='lvm/sys-root'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint='lvm/sys-root'  
d19dfc15-d628-44da-a4e7-97269b289293
else
  search --no-floppy --fs-uuid --set=root d19dfc15-d628-44da-a4e7-97269b289293
fi
font=/usr/share/grub/unicode.pf2
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_US
  insmod gettext
fi
terminal_output gfxterm
set timeout=5
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-d19dfc15-d628-44da-a4e7-97269b289293' {
load_video
insmod gzio
insmod part_msdos
insmod lvm
insmod ext2
set root='lvm/sys-boot'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint='lvm/sys-boot'  
89e952f3-c83a-4911-bab9-7c8f5a1b8228
else
  search --no-floppy --fs-uuid --set=root 
89e952f3-c83a-4911-bab9-7c8f5a1b8228
fi
echo'Loading Linux 3.10-3-amd64 ...'
linux   /vmlinuz-3.10-3-amd64 root=/dev/mapper/sys-root ro  quiet
echo'Loading initial ramdisk ...'
initrd  /initrd.img-3.10-3-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option 
'gnulinux-advanced-d19dfc15-d628-44da-a4e7-97269b289293' {
menuentry 'Debian GNU/Linux, with Linux 3.10-3-amd64' --class debian 
--class gnu-linux --class gnu --class os $menuentry_id_option 
'gnulinux-3.10-3-amd64-advanced-d19dfc15-d628-44da-a4e7-97269b289293' {
load_video
insmod gzio
insmod part_msdos
insmod lvm
insmod ext2
set root='lvm/sys-boot'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint='lvm/sys-boot' 
 89e952f3-c83a-4911-bab9-7c8f5a1b8228
else
  search --no-floppy --fs-uuid --set=root 
89e952f3-c83a-4911-bab9-7c8f5a1b8228
fi
echo'Loading Linux 3.10-3-amd64 ...'
linux   /vmlinuz-3.10-3-amd64 root=/dev/mapper/sys-root ro 

Bug#725732: (no subject)

2013-10-07 Thread Michael Lustfield
This is indeed a module that was added as of 1.5.4. It's also stable and seems
to be used by a large number of people as a third party module. When 1.5.x
becomes stable (1.6.0 will be the mainline), I don't see any reason to not add
this to -extras.

-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#733971: nginx-full: please provide XML entities

2014-01-03 Thread Michael Lustfield
 On Fri, Jan 03, 2014 at 11:10:34AM +0200, Christos Trochalakis wrote:
  On Thu, Jan 02, 2014 at 07:38:51PM +0100, Toni Mueller wrote:
  I recently discovered that the XSLT module does not work very well
  because of a missing list of entities. So I went to the W3C and then
  generated one, which works OK at my side. It would be nice if you could
  include the file with the next version(s) of the package.
  Yes, we could ship a sample dtd with nginx-doc package.

 I rather suggest shipping it with nginx-full, as one needs the file in
 case a backend does emit the entity references, instead of the binary
 code points. Eg. I need it to process output from Plone.


It definitely won't be part of nginx-full. It will either be part of
nginx-doc or nginx-common. Where does this file need to physically sit in
order for Nginx to behave correctly and are any config options needed?


Bug#733971: nginx-full: please provide XML entities

2014-01-03 Thread Michael Lustfield
On Fri, Jan 3, 2014 at 9:03 AM, Toni Mueller supp...@oeko.net wrote:


 On Fri, Jan 03, 2014 at 08:42:17AM -0600, Michael Lustfield wrote:
  It definitely won't be part of nginx-full. It will either be part of

 Why? I am only aware of its usefulness in conjunction with the XSLT
 module.


Because nginx-full is the package for the full version of the nginx
binary. It will not have configuration files in it. This is what
nginx-common is for. It's for files that are common among the versions of
nginx binaries.



  nginx-doc or nginx-common. Where does this file need to physically sit in
  order for Nginx to behave correctly and are any config options needed?

 You can place it wherever you want, but you need to reference it from
 the configuration, like described here:

 http://nginx.org/en/docs/http/ngx_http_xslt_module.html#xml_entities


I'm not familiar with this module. What are the chances that admins will
want to change this file? Will the defaults suffice for anyone/everyone
(the 99.99%)?


Bug#733971: nginx-full: please provide XML entities

2014-01-03 Thread Michael Lustfield

   http://nginx.org/en/docs/http/ngx_http_xslt_module.html#xml_entities
  
  I'm not familiar with this module. What are the chances that admins will
  want to change this file? Will the defaults suffice for anyone/everyone
  (the 99.99%)?

 My estimate is that at least everyone who wants to proxy to Plone and
 use XSLT, will need it. I arrived at this conclusion because I got
 site-breaking errors without it (libxml2 parse errors in the middle of
 the page and 404s for pages that definitely exist).

 IOW, if you are an XSLT user, I suspect that you will need such a file
 unless your web pages are generated to contain no somesymbol; type
 entity references at all. I don't know what the default values that
 nginx (libxml2, to be specific) knows about w/o having such a file, are.
 Although I likely have no use for the bulk of the entries in that file,
 simply implementing the entire standard was easier and safer than
 picking a subset and shipping that.


That's perhaps a large way to say yes? I was just trying to ask a simpler
question. *If* an admin needs this file because they are using the xlst
module, will *this* file be exactly what 99.99% of people need with zero
modifications required?


Bug#644732: Sorry!

2014-02-17 Thread Michael Lustfield
2.5yr and I finally realize there's a bug here. That's entirely because I
changed my email before this bug was filed. I'm sorry about that and I'll try
to get this fixed.

-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#742652: Info received (Bug#742652: Acknowledgement (wheezy/backports nginx does not include basic_auth))

2014-03-25 Thread Michael Lustfield
oops. It happens. Thanks for following up to let us know.

On Wed, 26 Mar 2014 10:48:35 +1100
Paul Morahan p...@zot.org wrote:

 stupid user error, sorry. config was missing a line terminator.
 
 - Paul
 


-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#737176: (no subject)

2014-06-26 Thread Michael Lustfield
I'm looking at the source package and have this line in mime.types.

application/javascriptjs;

It looks like you're using an Ubuntu version of the package. Could you verify
that the issue is present in Debian testing?

-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#707069: Not Convinced

2014-06-26 Thread Michael Lustfield
This still seems like a much larger headache than it's worth. As for point #2,
gzip can do a lot to compress data, especially white space. It does have some
nice features, but it seems like a large headache that I don't see going away.

-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#732330: (no subject)

2014-06-26 Thread Michael Lustfield
tags 732330 + wontfix
close 732330
thanks

This is not a bug in our packaging. It is a request to modify our packaging to
make it easier for others to modify it for themselves. Honestly, this is a
ridiculous reason. It's not even for an edge case of users. It's for one
person. This packaging is already very easy to modify if you want to build your
own flavor from it.

We won't be making any changes for this.
-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#733971: done

2014-06-26 Thread Michael Lustfield
This has been added to the documentation and will be fixed with the next
release.

-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#738543: (no subject)

2014-06-26 Thread Michael Lustfield
This appears to already be in nginx-extras. Are you having issues with it?

-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#765782: nginx: The sample TLS config should recommend a better cipher list

2014-10-22 Thread Michael Lustfield
Sorry for the long delay in response. I've been doing a lot of
thinking on this one.

What I personally use:
ssl_ciphers EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384
EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4
EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS;

What you're suggesting:
ssl_ciphers 
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA;

What's there now:
ssl_ciphers HIGH:!aNULL:!MD5 or HIGH:!aNULL:!MD5:!3DES;


1. Any one of these three will yield an A+ on SSL Labs test.
2. The current default offers stronger ciphers than the option you suggested.
3. Your version (and mine) would be a massive pile of clutter in the
default config file. It would likely cause a lot of confusion to newer
users.
4. The version included now already supports forward secrecy
5. My version prevents BEAST attacks and supports RC4. (Mine would
still be a lot of clutter)

I would consider an addition to nginx-docs that would explain ciphers
and provide a list of ssl_ciphers that could be used that would also
explain what they provide. However, I don't see any current need to
change the default and see reason (above) to not change it.

This is obviously open for discussion (not debate), but right now I'm
sold on keeping what we have currently.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#765782: nginx: The sample TLS config should recommend a better cipher list

2014-10-27 Thread Michael Lustfield
Linking to some third party site in hopes that their documentation will always
be there and be the best option seems to be in bad taste, in my opinion.

To me, it seems better practice to assume that an admin looking into changing
cipher lists will know how to locate relevant information (including their
list) and then tailor it to suite their needs.

If we were to include a link to mozilla recommendations, then it would seem to
make sense to also link to ssllabs as well as cipherli.st.

-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#767456: disable SSLv3 by default

2014-10-31 Thread Michael Lustfield
Yup, that's correct.
http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_protocols
SSLv3 is /currently/ enabled by default.

On Fri, Oct 31, 2014 at 9:37 AM, Thijs Kinkhorst th...@debian.org wrote:
 Hi Thomas,

 On Fri, October 31, 2014 12:48, Thomas Ward (Dark-Net) wrote:
 fixed 1.6.2-3
 thanks

 Confirmed: This was done already.  The commit this was done in was
 this one:
 http://anonscm.debian.org/cgit/collab-maint/nginx.git/commit/?id=9a4e0f0a698bee2b03b7f417ad9286e5eb22141e

 Thanks. That's certainly an improvement.

 It seems though that from reading the code, that if you omit an explicit
 ssl_protocols declaration in your config, you will still get SSLv3. Is
 that correct?


 Cheers,
 Thijs



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#771609: nginx: Include syntax highlighting for vim

2014-11-30 Thread Michael Lustfield
This sounds incredible. I'm sure this patch work perfect and would love adding
it. I just have one question...

+  - ftdetect/nginx.vim
+  - indent/nginx.vim
+  - syntax/nginx.vim

Do these files already exist in the package? Should they be included in this
patch?

-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#730645: (no subject)

2015-01-21 Thread Michael Lustfield
tags 730645 + wontfix
thanks

I'm marking this as won't fix because of the previously mentioned reasons.

-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#773301: (no subject)

2015-01-21 Thread Michael Lustfield
tags 773301 + wontfix
thanks

I'm marking this as won't fix because of the previously mentioned reasons. I'm
leaving it open for the moment because I'm still open to options... if they
exist.

-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#774464: closed by Michael Lustfield mich...@lustfield.net ()

2015-01-19 Thread Michael Lustfield
The Linux FS hierarchy [1] is pretty self-explanatory and standard.
Unfortunately, many admins don't bother to actually read and
understand what the heck is going on in their system. They have a
tendency to follow poor documentation without verifying the quality of
it. It's a bit disturbing that the archlinux wiki has that, but at the
same time, it's edited by users.

We can't really police all documentation to ensure people use common
sense. As much as it's not our place to police all documentation on
the Internet, it's also not our place to protect users from every
single silly thing they may consider doing. It's taking
--no-preserve-root, and going a step further. Sure, this one could be
a simple patch. It's a patch that isn't needed, though.

I'm sorry to be blunt and perhaps a little rude, but there's only so
much hand-holding and so on that should be provided. In my book, this
one is well past the limit.

I do have some ideas to help with this blind assumption that package
territory is also user territory, but there's only so much that people
will read. They obviously aren't bothering to read the top comment on
the default nginx config.

[1] http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

On Fri, Jan 16, 2015 at 3:40 PM, Arnout Engelen arn...@bzzt.net wrote:
 I've now verified that this is expected behavior. Regardless of whether we
 use /usr/share or /var/www, we have to expectation to retain user changes
 to
 index.html. We won't be making any change to preserve user changes to
 anything
 outside of /etc.


 That is, of course, your call as maintainer.

 I do still feel we're not being responsible with our users' data here. Even
 though
 they shouldn't have been messing with /usr/share, a quick internet search
 for
 /usr/share/nginx/html/index.html reveals plenty of people doing just that.

 Arch's wiki even appears to encourage it:

 It is assumed that you use the default location for documents
 (/usr/share/nginx/html). If that is not the case, substitute your path
 instead. - https://wiki.archlinux.org/index.php/Nginx#Configuring

 Would you consider a patch that backs the file up when it's changed?
 Shouldn't be a big change:
 we don't need to go to great lengths to support this situation, but just not
 losing the file would
 be nice :)


 Yours,

 Arnout


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#773332: (no subject)

2015-01-11 Thread Michael Lustfield
I've added a comment in the sample/default nginx configuration file.

Any beginner should be reading the sample. Anyone else should be aware of these
issues.

-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#773301: (no subject)

2015-01-11 Thread Michael Lustfield
I haven't had any luck finding a decent option. Currently, there are no plans
to bring naxsi back and mod_security doesn't look to be a great option either.
As Thomas mentioned, adding modules means we get to constantly deal with
updates of both the module and nginx. I'm not sure I see any viable options to
provide any sort of WAF at this moment.

-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#652108: (no subject)

2015-01-11 Thread Michael Lustfield
I'm curious... should we keep this open or close it?

-- 
Michael Lustfield


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



  1   2   3   4   >