[Bug 663319] Re: Need rebuild for 10.10
spidernik84, I observed that Ubuntu was being increasingly buggy with each release and have since moved all my Ubuntu boxes to Debian. -- You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. https://bugs.launchpad.net/bugs/663319 Title: Need rebuild for 10.10 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 384017] Re: Loading /etc/bash_completion is slow
Loading /etc/bash_completion takes 3 seconds on my Alix-based system (which has an AMD Geode 500 MHz CPU). Bash completions are loaded in a number of places including via /etc/profile. A non-invasive way to disable this is to add BASH_COMPLETION=1 to the start of /etc/profile. /etc/profile.d/bash_completion.sh will only load /etc/bash_completion if BASH_COMPLETION is the empty string. If you get an error: sed: can't read 1: No such file or directory Then something else is still trying to load /etc/bash_completion. In my base, this was ~/.bashrc. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/384017 Title: Loading /etc/bash_completion is slow -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 67811] Re: Takes all CPU time
I'm using backuppc version 3.1.0-6ubuntu4 on Ubuntu 9.10. I'm using fairly recent hardware (my backup server uses an Intel Atom 330 CPU, a 1.6 GHz dual-core CPU), yet, this effects me. Here's some of the output of top during a backup: 28539 backuppc 20 0 202m 141m 1368 R 98 4.0 5:26.85 BackupPC_dump 25224 backuppc 20 0 49288 7632 2408 R 79 0.2 1:56.49 ssh Both cores are nearly fully utilized. This remains relatively constant. (On the machine being backed up, a 4 core 2.3 GHz AMD Athlon(tm) II X4 605e, sshd usings just 10%-15% of one of the cores.) I'd suggest fixing this. To minimize the amount that a backup interferes with other programs running on a client, I changed RsyncClientPath to `nice -n 20 /usr/bin/rsync'. Unfortunately, using the same trick for the server does not work: changing SshPath to `nice -n 20 /usr/bin/ssh' results in: Error: SshPath must be a valid executable path (using /usr/bin/nice in space of nice doesn't work either.) It should be relatively painless to prefix the commands that backuppc exec's with a nice. Please do this. Thanks. -- Takes all CPU time https://bugs.launchpad.net/bugs/67811 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to backuppc in ubuntu. -- 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 67811] Re: Takes all CPU time
I'm using backuppc version 3.1.0-6ubuntu4 on Ubuntu 9.10. I'm using fairly recent hardware (my backup server uses an Intel Atom 330 CPU, a 1.6 GHz dual-core CPU), yet, this effects me. Here's some of the output of top during a backup: 28539 backuppc 20 0 202m 141m 1368 R 98 4.0 5:26.85 BackupPC_dump 25224 backuppc 20 0 49288 7632 2408 R 79 0.2 1:56.49 ssh Both cores are nearly fully utilized. This remains relatively constant. (On the machine being backed up, a 4 core 2.3 GHz AMD Athlon(tm) II X4 605e, sshd usings just 10%-15% of one of the cores.) I'd suggest fixing this. To minimize the amount that a backup interferes with other programs running on a client, I changed RsyncClientPath to `nice -n 20 /usr/bin/rsync'. Unfortunately, using the same trick for the server does not work: changing SshPath to `nice -n 20 /usr/bin/ssh' results in: Error: SshPath must be a valid executable path (using /usr/bin/nice in space of nice doesn't work either.) It should be relatively painless to prefix the commands that backuppc exec's with a nice. Please do this. Thanks. -- Takes all CPU time https://bugs.launchpad.net/bugs/67811 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 585791] [NEW] mythvideo's cronjob assumes root can access mythtv tv's home directory
Public bug reported: I mount mythtv's home directory using Kerberized NFS. The local root user is unable to access /home (unless root first kinits, of course). The result is that /etc/cron.hourly/mythvideo does not work for me. However, there is no good reason for it to fail and the fix is simple: simply fold the if into the su! The following works for me: #!/bin/sh #Hourly massive update to ensure users see graphics coming in for upcoming recordings and current recordings su mythtv -c ' if [ -f $HOME/.mythtv/config.xml ]; then /usr/bin/python /usr/share/mythtv/mythvideo/scripts/jamu.py -MW /var/lo\ g/mythtv/jamu.log; fi' ** Affects: mythvideo (Ubuntu) Importance: Undecided Status: New -- mythvideo's cronjob assumes root can access mythtv tv's home directory https://bugs.launchpad.net/bugs/585791 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 585791] Re: mythvideo's cronjob assumes root can access mythtv tv's home directory
I'm using Mythbuntu 9.10 and mythvideo 0.22.0+fixes22594-0ubuntu1. -- mythvideo's cronjob assumes root can access mythtv tv's home directory https://bugs.launchpad.net/bugs/585791 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 585791] Re: mythvideo's cronjob assumes root can access mythtv tv's home directory
** Attachment added: mythvideo http://launchpadlibrarian.net/49128884/mythvideo -- mythvideo's cronjob assumes root can access mythtv tv's home directory https://bugs.launchpad.net/bugs/585791 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 526999] Re: Password is ignored on local login, even for root
** Attachment added: substack-kerberos-unix http://launchpadlibrarian.net/44772381/substack-kerberos-unix -- Password is ignored on local login, even for root https://bugs.launchpad.net/bugs/526999 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 526999] Re: Password is ignored on local login, even for root
The file attached to comment #2 is the incorrect version of the file (that is the bad version created by auth-client-config). Use the version attached to comment #3. ** Attachment removed: /etc/pam.d/common-auth http://launchpadlibrarian.net/44772090/common-auth ** This bug has been flagged as a security vulnerability -- Password is ignored on local login, even for root https://bugs.launchpad.net/bugs/526999 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 526999] Re: Password is ignored on local login, even for root
This bug affects me. To work around it, I do the following: - Run sudo auth-client-config -a -p kerberos_example - Change /etc/pam.d/common-auth to use the attached file. - Create /etc/pam.d/substack-kerberos-unix based on the attached file. These files are under GPL v2 of the License, or (at your option) any later version. Note that it is essential to not simply drop substack-kerberos-unix into common-auth as this prevents later authentication modules from running (which, e.g., sshd relies on). These files (or something similar) should be integrated into /etc/auth- client-config/profile.d/acc-default . ** Attachment added: /etc/pam.d/common-auth http://launchpadlibrarian.net/44772090/common-auth -- Password is ignored on local login, even for root https://bugs.launchpad.net/bugs/526999 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 526999] Re: Password is ignored on local login, even for root
** Attachment added: common-auth http://launchpadlibrarian.net/44772333/common-auth -- Password is ignored on local login, even for root https://bugs.launchpad.net/bugs/526999 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 566665] [NEW] pam_mkhomedir should be optional, not required
Public bug reported: Binary package hint: auth-client-config Using the kerberos_example profile in /etc/auth-client-config/profile.d /acc-default, pam_mkhomedir is required. It should instead be optional. I'm mounting /home over NFS and root does not have permission to create files in /home. The result is that I cannot log in as a normal user if that user's home directory does not exist. Also, it is impossible to su to such users, which is my real problem. Instead of: pam_session=session requiredpam_mkhomedir.so umask=0022 skel=/etc/skel This line should read: pam_session=session optionalpam_mkhomedir.so umask=0022 skel=/etc/skel ** Affects: auth-client-config (Ubuntu) Importance: Undecided Status: New -- pam_mkhomedir should be optional, not required https://bugs.launchpad.net/bugs/55 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 409739] [NEW] alternate s3 servers / http_proxy
Public bug reported: Binary package hint: deja-dup I'm using my own S3 server. deja-dup does not support setting the S3 server (i.e., it appears to be hard coded to use aws.amazon.com). Generally this is not a problem if the program would respect the http proxy setting, however, deja-dup does not appear to do this. When I run deja-dup as follows: http_proxy=http://localhost:8080 deja-dup it fails and I do not see any access attempts in my S3 server's logs. Thanks. ProblemType: Bug Architecture: i386 DistroRelease: Ubuntu 9.04 ExecutablePath: /usr/bin/deja-dup Package: deja-dup 7.4-0ubuntu2 ProcEnviron: SHELL=/bin/bash PATH=(custom, user) LANG=en_US.UTF-8 SourcePackage: deja-dup Uname: Linux 2.6.28-14-generic i686 ** Affects: deja-dup (Ubuntu) Importance: Undecided Status: New ** Tags: apport-bug i386 -- alternate s3 servers / http_proxy https://bugs.launchpad.net/bugs/409739 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 409739] Re: alternate s3 servers / http_proxy
** Attachment added: Dependencies.txt http://launchpadlibrarian.net/29953956/Dependencies.txt ** Attachment added: ProcMaps.txt http://launchpadlibrarian.net/29953957/ProcMaps.txt ** Attachment added: ProcStatus.txt http://launchpadlibrarian.net/29953959/ProcStatus.txt -- alternate s3 servers / http_proxy https://bugs.launchpad.net/bugs/409739 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 136252] Re: [gutsy] mdadm, initramfs missing ARRAY lines
After updating to 9.04, I experienced a similar problem.
I have three md devices: md0 (/dev/sd{a,b}1, swap), md1 (/dev/sd{a,b}2, root),
and md4 (/dev/sd{a,b}3, home). On boot, mdadm would incorrectly detect that
/dev/sda was an md device and create it. Upon inspection (using mdadm -E),
/dev/sda, /dev/sdb, /dev/sda3, and /dev/sdb3 all had the same super block.
Zeroing the /dev/sda and /dev/sdb ones resulted in also zeroing the /dev/sda3
and /dev/sdb3 ones (which suggests that the /dev/sda3 superblock was being
detected as the /dev/sda one).
I changed my /etc/mdadm/mdadm.conf to have
DEVICE /dev/sd??*
rather than
DEVICE partitions
and the system booted fine.
While searching for this problem, I found that some people reported that
mdadm --incremental would not create their arrays properly whereas
mdadm -As worked fine. I extracted the initrd (kernel 2.6.28-11-generic)
and found that this is indeed how the arrays are being built. I didn't check
whether 8.10 uses --incremental or --assemble, but perhaps this is a starting
point for further investigation of this issue.
--
[gutsy] mdadm, initramfs missing ARRAY lines
https://bugs.launchpad.net/bugs/136252
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
