[Bug 1187742] Re: [patch] upstart job for freeradius

2015-02-24 Thread urusha
To reload freeradius properly upstart job should be fixed. Here is the
patch.

** Patch added: freeradius.patch
   
https://bugs.launchpad.net/ubuntu/+source/freeradius/+bug/1187742/+attachment/4326241/+files/freeradius.patch

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to freeradius in Ubuntu.
https://bugs.launchpad.net/bugs/1187742

Title:
  [patch] upstart job for freeradius

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/freeradius/+bug/1187742/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1307473] Re: guest hang due to missing clock interrupt

2014-07-03 Thread urusha
After installing kernel 3.15.1-031501-generic from kernel-ppa, both
machines work without issues from 2014-06-25. Seems it's kernel issue
that have already been solved upstream.

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu in Ubuntu.
https://bugs.launchpad.net/bugs/1307473

Title:
  guest hang due to missing clock interrupt

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1307473/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1307473] Re: guest hang due to missing clock interrupt

2014-06-24 Thread urusha
I have the same symptoms with two trusty-amd64 virtual hosts:
 * win2003, linux guests hang for a period of time (~5 seconds, half of a 
minute and more)
 * win2008 blue screen with the same message

This happens with kernels (host):
Linux vsrv7 3.13.0-27-generic #50-Ubuntu SMP Thu May 15 18:06:16 UTC 2014 
x86_64 x86_64 x86_64 GNU/Linux
Linux vsrv9 3.13.0-29-generic #53-Ubuntu SMP Wed Jun 4 21:00:20 UTC 2014 x86_64 
x86_64 x86_64 GNU/Linux
Qemu version: 2.0.0+dfsg-2ubuntu1.1

Here are qemu params of guests that definately hang:
* precise with 3.11:
qemu-system-x86_64 -enable-kvm -name m -S -machine 
pc-i440fx-trusty,accel=kvm,usb=off -m 4096 -realtime mlock=off -smp 
2,sockets=2,cores=1,threads=1 -uuid ab7f1e0b-e82e-ddb7-b743-903b8732e333 
-no-user-config -nodefaults -chardev 
socket,id=charmonitor,path=/var/lib/libvirt/qemu/m.monitor,server,nowait -mon 
chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot 
order=c,menu=on,strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 
-device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x4 -drive 
file=/dev/vg00/kvm_m_1,if=none,id=drive-scsi0-0-0-0,format=raw,cache=none,aio=native
 -device 
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0
 -netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=29 -device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:3a:76:ad,bus=pci.0,addr=0x3 
-chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 
-vnc 127.0.0.1:3 -device VGA,id=video0,bus=pci.0,addr=0x2 -device 
virtio-balloon-p
 ci,id=balloon0,bus=pci.0,addr=0x5
* win 2008 r2:
qemu-system-x86_64 -enable-kvm -name ts2 -S -machine pc-1.0,accel=kvm,usb=off 
-m 1 -realtime mlock=off -smp 16,sockets=16,cores=1,threads=1 -uuid 
4df29f97-7e47-8af3-0009-a5395c28e3c5 -no-user-config -nodefaults -chardev 
socket,id=charmonitor,path=/var/lib/libvirt/qemu/ts2.monitor,server,nowait -mon 
chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown 
-boot order=c,menu=on,strict=on -device 
piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device 
virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x8 -drive 
file=/dev/vg00/kvm_ts2_1,if=none,id=drive-scsi0-0-0-0,format=raw,cache=none,aio=native
 -device 
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0
 -drive 
file=/dev/vg00/kvm_ts2_2,if=none,id=drive-scsi0-0-0-1,format=raw,cache=none,aio=native
 -device 
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1
 -drive 
file=/dev/vg00/kvm_ts2_3,if=none,id=drive-scsi0-0-0-2,format=raw,cache=none,aio=native
 -device scsi
 
-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=2,drive=drive-scsi0-0-0-2,id=scsi0-0-0-2
 -netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=30 -device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:ac:28:3a,bus=pci.0,addr=0x3 
-chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 
-device usb-tablet,id=input0 -vnc 127.0.0.1:0 -device 
VGA,id=video0,bus=pci.0,addr=0x2 -device 
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4
* win 2003:
qemu-system-x86_64 -enable-kvm -name ts4 -S -machine 
pc-i440fx-trusty,accel=kvm,usb=off -m 8192 -realtime mlock=off -smp 
4,sockets=4,cores=1,threads=1 -uuid d9f9b238-5cb6-59a8-f3aa-ccfc6656040a 
-no-user-config -nodefaults -chardev 
socket,id=charmonitor,path=/var/lib/libvirt/qemu/ts4.monitor,server,nowait -mon 
chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown 
-boot order=c,menu=on,strict=on -device 
piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive 
file=/dev/vg00/kvm_ts4_1,if=none,id=drive-virtio-disk0,format=raw,cache=none,aio=native
 -device 
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0
 -netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=27 -device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:37:6b:8d,bus=pci.0,addr=0x3 
-chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 
-device usb-tablet,id=input0 -vnc 127.0.0.1:2 -device 
VGA,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=ballo
 on0,bus=pci.0,addr=0x5

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu in Ubuntu.
https://bugs.launchpad.net/bugs/1307473

Title:
  guest hang due to missing clock interrupt

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1307473/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1307473] Re: guest hang due to missing clock interrupt

2014-06-24 Thread urusha
** Attachment added: dmesg of precise guest while hanging
   
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1307473/+attachment/4137970/+files/dmesg.txt

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu in Ubuntu.
https://bugs.launchpad.net/bugs/1307473

Title:
  guest hang due to missing clock interrupt

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1307473/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1307473] Re: guest hang due to missing clock interrupt

2014-06-24 Thread urusha
Also, seems that these bugs are DUPs:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1308341
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1332409

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu in Ubuntu.
https://bugs.launchpad.net/bugs/1307473

Title:
  guest hang due to missing clock interrupt

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1307473/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1308341] Re: Multiple CPUs causes blue screen on Windows guest (14.04 regression)

2014-06-24 Thread urusha
Could it be DUP of
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1307473 ?

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu in Ubuntu.
https://bugs.launchpad.net/bugs/1308341

Title:
  Multiple CPUs causes blue screen on Windows guest (14.04 regression)

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1308341/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1088136] Re: AUTH cannot handle a request with an initial-response over 2048 bytes (GSSAPI-related)

2013-04-02 Thread urusha
The package from precise-proposed 4.76-3ubuntu3.2 fixes this bug. So,
I'll change the tag.


** Tags removed: verification-needed
** Tags added: verification-done

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to exim4 in Ubuntu.
https://bugs.launchpad.net/bugs/1088136

Title:
  AUTH cannot handle a request with an initial-response over 2048 bytes
  (GSSAPI-related)

To manage notifications about this bug go to:
https://bugs.launchpad.net/exim/+bug/1088136/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1088136] Re: AUTH cannot handle a request with an initial-response over 2048 bytes (GSSAPI-related)

2012-12-10 Thread urusha
** Description changed:

  smtp_cmd_buffer_size is currently 2048 bytes.  2048 bytes is not sufficient 
for
  clients that send an AUTH with an initial-response for GSSAPI when Windows
  Kerberos tickets are used that contain a PAC -- as of Windows 2003, the 
maximum
  ticket size is 12000 bytes.
  
  MUAs that use AUTH GSSAPI without an initial-response are not impacted by the
  2048 limit, since the remainder of the SASL session is handled by 
auth_get_data
  in Exim, which uses big_buffer and has sufficient space to process large
  Kerberos tickets.
  
  Thunderbird will always send an AUTH GSSAPI with an initial-response, which
  makes it subject to the 2048 byte limit.  A large Kerberos ticket will easily
  surpass 2048 bytes when base64-encoded, causing the AUTH to fail.
  
  RFC 4954 recommends 12288 bytes as a line limit to handle AUTH.  For a base64
  encoded max-size Windows Kerberos ticket, at least 16000 bytes are needed.
  
  This bug is fixed upstream (4.77). It would be nice to backport it to
  precise.
  
  [Impact]
  smtp_cmd_buffer_size is currently 2048 bytes.  2048 bytes is not sufficient 
for
  clients that send an AUTH with an initial-response for GSSAPI when Windows
  Kerberos tickets are used that contain a PAC. For a base64
  encoded max-size Windows Kerberos ticket, at least 16000 bytes are needed.
+ Fixing this bug lets us to use exim4 smtp server with AD kerberos 
authentication and windows clients, so I think it's worth fixing.
  
  [Test Case]
- 1. Configure exim4 to use GSSAPI auth.
- 2. Configure thunderbird to use GSSAPI smtp auth on windows 
xp/vista/7/2003/2008.
- 3. Auth will always fail.
+ 1. You need a configured AD/samba4 domain
+ 2. Configure exim4 to use GSSAPI auth (here is dovecot method):
+  - # apt-get instal dovecot-imapd exim4-daemon-heavy
+  - /etc/krb5.keytab should contain 'smtp/fqdn.host.name@YOUR.REALM' 
credentials (import it somehow), just for test make it readable for all. (chmod 
644 /etc/krb5.keytab)
+  - your dovecot config should contain something like this:
+ auth_mechanisms = gssapi
+ auth_default_realm = YOUR.REALM
+ auth_realms = YOUR.REALM
+ auth_gssapi_hostname = fqdn.host.name
+ auth_krb5_keytab = /etc/krb5.keytab
+ service auth {
+   unix_listener auth-client {
+ mode = 0600
+ user = Debian-exim
+   }
+  - your exim's 'begin authenticators' section of the config should contain 
something like:
+ auth_gssapi:
+ driver= dovecot
+ public_name   = GSSAPI
+ server_socket = /var/run/dovecot/auth-client
+ server_set_id = $auth1
+ 3. Configure thunderbird to use GSSAPI smtp auth on windows 
xp/vista/7/2003/2008 (member of your AD domain).
+  - install thunderbird or use thunderbird portable
+  - configure any (e.g. it could be nonexisting at all) IMAP/POP mail account 
in thunderbird (using some domain member account)
+  - in account settings set authentication address/port to your exim server, 
username to your domain username, auth method to 'Kerberos/GSSAPI'
+ 4. Try to send mail. Auth will always fail. In exim's log there will be 
messages like these:
+ 2012-12-09 00:04:46 SMTP syntax error in AUTH GSSAPI 

[Bug 1088136] Re: AUTH cannot handle a request with an initial-response over 2048 bytes (GSSAPI-related)

2012-12-10 Thread urusha
Hi!
I'm confirming that this bug is fixed in raring an quantal. How could I mark it 
Fix released for raring?
I've also updated bug description, made test case more detailed, is it detailed 
enough now?
And here is updated debdiff.
Thank you.


** Patch added: updated exim4.debdiff
   
https://bugs.launchpad.net/ubuntu/+source/exim4/+bug/1088136/+attachment/3456247/+files/exim4.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to exim4 in Ubuntu.
https://bugs.launchpad.net/bugs/1088136

Title:
  AUTH cannot handle a request with an initial-response over 2048 bytes
  (GSSAPI-related)

To manage notifications about this bug go to:
https://bugs.launchpad.net/exim/+bug/1088136/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1088136] [NEW] AUTH cannot handle a request with an initial-response over 2048 bytes (GSSAPI-related)

2012-12-09 Thread urusha
Public bug reported:

smtp_cmd_buffer_size is currently 2048 bytes.  2048 bytes is not sufficient for
clients that send an AUTH with an initial-response for GSSAPI when Windows
Kerberos tickets are used that contain a PAC -- as of Windows 2003, the maximum
ticket size is 12000 bytes.

MUAs that use AUTH GSSAPI without an initial-response are not impacted by the
2048 limit, since the remainder of the SASL session is handled by auth_get_data
in Exim, which uses big_buffer and has sufficient space to process large
Kerberos tickets.

Thunderbird will always send an AUTH GSSAPI with an initial-response, which
makes it subject to the 2048 byte limit.  A large Kerberos ticket will easily
surpass 2048 bytes when base64-encoded, causing the AUTH to fail.

RFC 4954 recommends 12288 bytes as a line limit to handle AUTH.  For a base64
encoded max-size Windows Kerberos ticket, at least 16000 bytes are needed.

This bug is fixed upstream (4.77). It would be nice to backport it to
precise.

[Impact]
smtp_cmd_buffer_size is currently 2048 bytes.  2048 bytes is not sufficient for
clients that send an AUTH with an initial-response for GSSAPI when Windows
Kerberos tickets are used that contain a PAC. For a base64
encoded max-size Windows Kerberos ticket, at least 16000 bytes are needed.

[Test Case]
1. Configure exim4 to use GSSAPI auth.
2. Configure thunderbird to use GSSAPI smtp auth on windows 
xp/vista/7/2003/2008.
3. Auth will always fail.

[Regression Potential]
The fix for this bug is one-line-patch applied to upstream (4.77) more than 
year ago, so it already has got sufficient testing.

** Affects: exim
 Importance: Unknown
 Status: Unknown

** Affects: exim4 (Ubuntu)
 Importance: Undecided
 Status: New

** Package changed: heimdal (Ubuntu) = exim4 (Ubuntu)

** Description changed:

  smtp_cmd_buffer_size is currently 2048 bytes.  2048 bytes is not sufficient 
for
  clients that send an AUTH with an initial-response for GSSAPI when Windows
  Kerberos tickets are used that contain a PAC -- as of Windows 2003, the 
maximum
  ticket size is 12000 bytes.
  
  MUAs that use AUTH GSSAPI without an initial-response are not impacted by the
  2048 limit, since the remainder of the SASL session is handled by 
auth_get_data
  in Exim, which uses big_buffer and has sufficient space to process large
  Kerberos tickets.
  
  Thunderbird will always send an AUTH GSSAPI with an initial-response, which
  makes it subject to the 2048 byte limit.  A large Kerberos ticket will easily
  surpass 2048 bytes when base64-encoded, causing the AUTH to fail.
  
  RFC 4954 recommends 12288 bytes as a line limit to handle AUTH.  For a base64
- encoded max-size Windows Kerberos ticket, at least 16000 bytes are needed. 
+ encoded max-size Windows Kerberos ticket, at least 16000 bytes are needed.
  
- This bug is fixed upstream (4.77).
+ This bug is fixed upstream (4.77). It would be nice to backport it to
+ precise.
  
  [Impact]
  smtp_cmd_buffer_size is currently 2048 bytes.  2048 bytes is not sufficient 
for
  clients that send an AUTH with an initial-response for GSSAPI when Windows
  Kerberos tickets are used that contain a PAC. For a base64
  encoded max-size Windows Kerberos ticket, at least 16000 bytes are needed.
  
  [Test Case]
  1. Configure exim4 to use GSSAPI auth.
  2. Configure thunderbird to use GSSAPI smtp auth on windows 
xp/vista/7/2003/2008.
  3. Auth will always fail.
  
  [Regression Potential]
  The fix for this bug is one-line-patch applied to upstream (4.77) more than 
year ago, so it already has got sufficient testing.

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to exim4 in Ubuntu.
https://bugs.launchpad.net/bugs/1088136

Title:
  AUTH cannot handle a request with an initial-response over 2048 bytes
  (GSSAPI-related)

To manage notifications about this bug go to:
https://bugs.launchpad.net/exim/+bug/1088136/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1088136] Re: AUTH cannot handle a request with an initial-response over 2048 bytes (GSSAPI-related)

2012-12-09 Thread urusha
This debdiff includes fix for this bug.

** Patch added: exim4 debdiff
   
https://bugs.launchpad.net/ubuntu/+source/exim4/+bug/1088136/+attachment/3455194/+files/exim4.debdiff

** Bug watch added: bugs.exim.org/ #879
   http://bugs.exim.org/show_bug.cgi?id=879

** Also affects: exim via
   http://bugs.exim.org/show_bug.cgi?id=879
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to exim4 in Ubuntu.
https://bugs.launchpad.net/bugs/1088136

Title:
  AUTH cannot handle a request with an initial-response over 2048 bytes
  (GSSAPI-related)

To manage notifications about this bug go to:
https://bugs.launchpad.net/exim/+bug/1088136/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1004465] Re: heimdal and mit kinit doesn't handle expired credentials

2012-07-28 Thread urusha
mit kinit has been fixed here:
https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/988520

** Changed in: krb5 (Ubuntu)
   Status: Confirmed = Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to krb5 in Ubuntu.
https://bugs.launchpad.net/bugs/1004465

Title:
  heimdal and mit kinit doesn't handle expired credentials

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/heimdal/+bug/1004465/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1004465] Re: heimdal and mit kinit doesn't handle expired credentials

2012-05-28 Thread urusha
** Bug watch added: Debian Bug tracker #674640
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674640

** Also affects: heimdal (Debian) via
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674640
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to krb5 in Ubuntu.
https://bugs.launchpad.net/bugs/1004465

Title:
  heimdal and mit kinit doesn't handle expired credentials

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/heimdal/+bug/1004465/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1004465] Re: heimdal and mit kinit doesn't handle expired credentials

2012-05-25 Thread urusha
** Also affects: krb5 (Ubuntu)
   Importance: Undecided
   Status: New

** Tags added: expired heimdal kerberos kinit mit password

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to krb5 in Ubuntu.
https://bugs.launchpad.net/bugs/1004465

Title:
  heimdal and mit kinit doesn't handle expired credentials

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/heimdal/+bug/1004465/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1003369] Re: kinit can't change expired password with kerberos pre-authentication enabled

2012-05-25 Thread urusha
Hi.
Seems, I've just filled another bug report about this issue (found your report 
only after). It's similar to yours but also affects heimdal's kinit. Can you 
confirm it? Looks like for now precise contains no kerberos which could handle 
expired passwords.
Thanks.

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to krb5 in Ubuntu.
https://bugs.launchpad.net/bugs/1003369

Title:
  kinit can't change expired password with kerberos pre-authentication
  enabled

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1003369/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 995956] Re: cgconfig upstart job should start earlier and mount all available cgroup types by default

2012-05-25 Thread urusha
Hi. Are you talking about binaries in /usr/*bin directories? If so, then you 
mean that system can be booted without /usr(bin,sbin) somehow? If so, I'm very 
surprised about that ability (I see it can be used somehow for ro-mounted /usr 
and, maybe, with embedded devices or small-size storages), but anyway:
a) Is this technique used such widely, then we can't change defaults? (it's 
users can make cgconfig.override too...)
b) why then not to move binaries into /bin, /sbin? Despite the fact this 
package is buggy, it's very system-internal, isn't it?

If I see you wrong, please explain.
Thanks

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to libcgroup in Ubuntu.
https://bugs.launchpad.net/bugs/995956

Title:
  cgconfig upstart job should start earlier and mount all available
  cgroup types by default

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libcgroup/+bug/995956/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 995956] Re: cgconfig upstart job should start earlier and mount all available cgroup types by default

2012-05-25 Thread urusha
Well, I mean exactly the same, my english isn't well:). And then I asked
- are there many people using /usr on another partition than /? If no -
why not to change defaults? If yes, is it a problem to just move
binaries to /bin, /sbin?

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to libcgroup in Ubuntu.
https://bugs.launchpad.net/bugs/995956

Title:
  cgconfig upstart job should start earlier and mount all available
  cgroup types by default

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libcgroup/+bug/995956/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 995956] Re: cgconfig upstart job should start earlier and mount all available cgroup types by default

2012-05-25 Thread urusha
And I've just thought: is it possible to implement something like
mounted MOUNTPOINT=/sys and mounted MOUNTPOINT=/usr? Does upstart
support nonexistent mount points (not fails if there is no /usr mount
point)?

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to libcgroup in Ubuntu.
https://bugs.launchpad.net/bugs/995956

Title:
  cgconfig upstart job should start earlier and mount all available
  cgroup types by default

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libcgroup/+bug/995956/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 995956] Re: cgconfig upstart job should start earlier and mount all available cgroup types by default

2012-05-09 Thread urusha
I see you. The critical issue is point 1, while point 2 is more a
configuration issue. Now after your explanation I agree with your
opinion about point 2. A better way is to add mount points
(cpuset,blkio) to the default configuration file. What should I do for
it then?

Well, I'm not against changing the title if it's needed.

The main purpose for me is to run daemons with limits. Upstart doesn't handle 
cgroups and cgroup limits at the moment, so the final optimal way I found is:
a) use cgconfig.conf to set limits
b) use service.override and cgexec to run daemon in the special cgroup. cups 
example:
  exec cgexec -g cpuset:daemon-cups /usr/sbin/cupsd -F

cgred could also be used, but if you use lxc on the same machine it
affects all lxc container's daemons (cups) too and I don't need such
limits. Anyway point 1 of this bug report is needed for this method to
work too (cgconfig should start before cups).

Could you give me a link about libcgroup+libvirt problems?

Thanks.

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to libcgroup in Ubuntu.
https://bugs.launchpad.net/bugs/995956

Title:
  cgconfig upstart job should start earlier and mount all available
  cgroup types by default

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libcgroup/+bug/995956/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 995956] [NEW] cgconfig upstart job should start earlier and mount all available cgroup types by default

2012-05-07 Thread urusha
Public bug reported:

ubuntu 12.04 LTS, amd64
cgroup-bin 0.37.1-1ubuntu10

1. cgconfig upstart job should start earlier.
/etc/init/cgconfig.conf contains this:
  start on runlevel [2345]
but should contain this (like cgroup-lite.conf does)
  start on mounted MOUNTPOINT=/sys

Why it's needed?  Imagine, I want cupsd to start with memory limit (cgroup 
called daemon-cups). To do this I edited configs:
/etc/cgconfig.conf
group daemon-cups {
memory {
memory.limit_in_bytes = 50M;
}
}

 /etc/cgrules.conf
   root:/usr/sbin/cupsd memory  daemon-cups

Now, after computer rebooted, I can see that daemon-cups cgroup is created but 
cupsd isn't in daemon-cups cgroup tasks. It appears there only after:
  service cups restart

That's because cups service started earlier than cgred service (and cgred 
service starts on started cgconfig).
Than imagine what if lxc will somehow start earlier than cgconfig? No, it won't 
start at all. So, I think this should be fixed.

2. cgconfig should mount all available cgroup types by default.
Default /etc/cgconfig.conf contains these:
mount {
cpu = /sys/fs//cgroup/cpu;
cpuacct = /sys/fs/cgroup/cpuacct;
devices = /sys/fs/cgroup/devices;
memory = /sys/fs/cgroup/memory;
freezer = /sys/fs/cgroup/freezer;
}

What if I  want to use LXC on the same machine and one container's config 
contains something like this:
  lxc.cgroup.cpuset.cpus = 1
Container will not start, because this cgroup type is not mounted by default 
with cgroup-bin package.
I think, the best way to fix this is to mount available cgroup fsystems via 
upstart job (the way cgroup-lite does it).  Another way is to change default 
/etc/cgconfig.conf (add mountpoints). But I would prefer the first solution 
(it's kernel independent).

3. After all these I'm asking you what is the reason of separation
cgroup-bin and cgroup-lite into different packages. Why not to just
disable cgrulesengd, cgconfigparser by default (using /etc/default
somehow)? For example, if I'm using LXC, I will likely be using
cgget/cgset or something.  And even if won't be using it what's wrong
with that these binaries are in my /usr/bin (100Kb)?

P.S.  cgconfig.conf : cpu = /sys/fs//cgroup/cpu; I believe double
slashes isn't needed here.

Thanks, hope it'll be fixed in LTS.

** Affects: libcgroup (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to libcgroup in Ubuntu.
https://bugs.launchpad.net/bugs/995956

Title:
  cgconfig upstart job should start earlier and mount all available
  cgroup types by default

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libcgroup/+bug/995956/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 947617] Re: After update, lxc does not start

2012-03-06 Thread urusha
Seems it's a mistake in /etc/apparmor.d/usr.bin.lxc-start
Don't know how to fix it, but if you want to make lxc work quickly (without 
apparmor):
ln -s /etc/apparmor.d/usr.bin.lxc-start 
/etc/apparmor.d/disable/usr.bin.lxc-start
service apparmor restart
lxc-start ..

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/947617

Title:
  After update, lxc does not start

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/947617/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 570944] Re: passwd : gives Authentication token manipulation error

2011-09-12 Thread urusha
Here is my solution:
1) copy winbind winbind-noauthtok unix-noauthtok files from attachments 
to /usr/share/pam-configs/ (with overwrite)
2) copy pam_winbind.conf from attachment to /etc/security/
3) run pam-auth-update and check Unix authentication (no use_authtok)  
Winbind NT/Active Directory authentication (no use_authtok), also uncheck 
Unix authentication  Winbind NT/Active Directory authentication
4) use it

What it is:
1) new configs.
  1. winbind - is the same as default winbind (you need to overwrite it) but:
a) without krb5_*, cached_login options, I think these should be placed in 
special config file /etc/security/pam_winbind.conf - this is much more 
customizable way to configure pam_winbind without any involving of 
pam-auth-update. Also this solves bug about not getting krb ticket and ccache 
when changing expired password on login (pam_winbind passwd section should 
contain krb5_* options too, but it doesn't)
b) increased Priority, it's to solve buggy changing expired password on 
login. Winbind should be before unix (like pam_krb5 does)
  2. winbind-noauthtok, unix-noauthtok - is the same as winbind and unix, but 
without use_authtok option. These configs conflicts with winbind, unix and 
cracklib, so you can't install winbind-noauthtok with winbind or cracklib
2) see 1-1-a
3) just changing configs in /etc/pam.d/ the right way
4) this solution has the next advantages:
  1. customizable - you may choose: use cracklib or not, pam-auth-update 
suggests different ways
  2. solves some existing bugs: allows you to change unix, wb password via 
passwd command (or any other graphical tools); allows to change expired unix, 
wb password on login; gets krb ticket and ccache after wb expired password has 
been changed; maybe some others...

To packages supporters:
  Why not to implement this in all pam modules packages (add unix, 
unix-noauthtok in libpam-runtime for example), while thinking about upgrading 
whole pam system?
  It would be really nice to add function of detecting if use use_authtok or 
not to pam-auth-update (just read configs of higher priority modules).

Some offtopic (to pam-auth-update supporters):
  Even if I use pam_winbind.conf option mkhomedir = yes it doesn't copy skel 
directory to new user home. So I'm forced to use pam_mkhomedir. But if I create 
config for it in /usr/share/pam-configs, it adds lines about making home 
derictories to /etc/pam.d/common-session-noninteractive too, and this is really 
BAD behavior. So the right way is to implement Session-noninteractive: 
section in config files, I think.

Thanks for attantion.

** Attachment added: winbind
   
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/570944/+attachment/2391119/+files/winbind

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to samba in Ubuntu.
https://bugs.launchpad.net/bugs/570944

Title:
  passwd : gives Authentication token manipulation error

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/570944/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 570944] Re: passwd : gives Authentication token manipulation error

2011-09-12 Thread urusha
** Attachment added: winbind-noauthtok
   
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/570944/+attachment/2391120/+files/winbind-noauthtok

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to samba in Ubuntu.
https://bugs.launchpad.net/bugs/570944

Title:
  passwd : gives Authentication token manipulation error

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/570944/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 570944] Re: passwd : gives Authentication token manipulation error

2011-09-12 Thread urusha
** Attachment added: unix-noauthtok
   
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/570944/+attachment/2391121/+files/unix-noauthtok

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to samba in Ubuntu.
https://bugs.launchpad.net/bugs/570944

Title:
  passwd : gives Authentication token manipulation error

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/570944/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 570944] Re: passwd : gives Authentication token manipulation error

2011-09-12 Thread urusha
** Attachment added: pam_winbind.conf
   
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/570944/+attachment/2391122/+files/pam_winbind.conf

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to samba in Ubuntu.
https://bugs.launchpad.net/bugs/570944

Title:
  passwd : gives Authentication token manipulation error

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/570944/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 570944] Re: passwd : gives Authentication token manipulation error

2011-09-12 Thread urusha
Oh, about offtopic - forget about it. Now I see - there is Session-
Interactive-Only: yes option.

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to samba in Ubuntu.
https://bugs.launchpad.net/bugs/570944

Title:
  passwd : gives Authentication token manipulation error

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/570944/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs