Bug#927829: goldencheetah: Strava sync seems impossible due to unsettable client secrets
Package: goldencheetah Version: 1:3.5~DEV1810-1 Severity: normal Dear Maintainer, Excited to find a OSS alternative to Strava, TrainerRoad, TrainingPeaks etc. However: When trying to authorise to my Strava account, I'm getting an "Host requires authentication (204)" error back from Strava. This suggests, after some searching, that this build is not being done with the registered client id in Strava. I can completely understand this given Debian policies, and the fact this is a DEV build. But, I've got a Strava "My API Application" created, and have a suitable client id and secret, but I can't find any way of setting this in Golden Cheetah. I see from the Golden Cheetah docs that these appear to be a compile-time constants, which is a problem - I'm amazed I can't set it in some configuration file. Without this, this package doesn't seem to be able to work for me - if I can't import several years of rides from Strava without recompiling Golden Cheetah myself then this package is of limited use. Is there no way by which these secrets can be set via configuration files? Many thanks, Matthew -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages goldencheetah depends on: ii libc6 2.28-8 ii libgcc1 1:8.3.0-6 ii libgl11.1.0-1 ii libglib2.0-0 2.58.3-1 ii libical3 3.0.4-3 ii libkmlbase1 1.3.0-7 ii libkmlconvenience11.3.0-7 ii libkmldom11.3.0-7 ii libkmlengine1 1.3.0-7 ii libpulse-mainloop-glib0 12.2-4 ii libpulse0 12.2-4 ii libqt5bluetooth5 5.11.3-2 ii libqt5charts5 5.11.3-2 ii libqt5concurrent5 5.11.3+dfsg1-1 ii libqt5core5a 5.11.3+dfsg1-1 ii libqt5gui55.11.3+dfsg1-1 ii libqt5multimedia5 5.11.3-2 ii libqt5multimediawidgets5 5.11.3-2 ii libqt5network55.11.3+dfsg1-1 ii libqt5opengl5 5.11.3+dfsg1-1 ii libqt5serialport5 5.11.3-2 ii libqt5sql55.11.3+dfsg1-1 ii libqt5sql5-sqlite 5.11.3+dfsg1-1 ii libqt5svg55.11.3-2 ii libqt5webkit5 5.212.0~alpha2-21 ii libqt5widgets55.11.3+dfsg1-1 ii libqt5xml55.11.3+dfsg1-1 ii libstdc++68.3.0-6 ii libusb-0.1-4 2:0.1.12-32 ii libvlc5 1:3.0.6-dmo5 ii zlib1g1:1.2.11.dfsg-1 goldencheetah recommends no packages. goldencheetah suggests no packages. -- no debconf information
Bug#851132: [debian-mysql] Bug#851132: /usr/sbin/mysqld: ssl_ciphers not working; mariadb built without TLS support?
On Wed, Jan 25, 2017 at 12:21:09PM +0200, Otto Kekäläinen wrote: > I am sorry but we have basically been forbidden from using OpenSSL in > Debian due to license reasons: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761911 > > If you can get somebody to change their opinion, then we could use > OpenSSL. But still it is sad OpenSSL has such an license. In the long > term migrating to something else would be good. Understood. I'm sorry if I came across as whining - been a long week. I would just hope that these issues are thoroughly and prominently documented so that we can take extra steps to try to secure installations and make informed decisions. Matthew
Bug#851132: [debian-mysql] Bug#851132: /usr/sbin/mysqld: ssl_ciphers not working; mariadb built without TLS support?
On Wed, Jan 25, 2017 at 09:44:00AM +0200, Otto Kekäläinen wrote: > Ok, this is now figured out. > > To activate YaSSL you must have 'ssl=on' in the config and no > ssl_cipher defined. Erm, ok, but this is somewhat terrifying - I can't disable insecure and broken ciphers? I basically would consider anything < TLSv1.2 insecure and I would expect to be able to restrict even the ciphers within TLSv1.2. This is in keeping with standard practise for apache, dovecot, postfix etc etc. Matthew
Bug#851132: /usr/sbin/mysqld: ssl_ciphers not working; mariadb built without TLS support?
Package: mariadb-server-core-10.1 Version: 10.1.20-3 Severity: important File: /usr/sbin/mysqld Hi, In my /etc/mysql/mariadb.conf.d/50-server.cnf file, I have ssl_cipher=TLSv1.2 However, on startup, the logs contain: 2017-01-12 8:53:04 139750636693376 [Warning] Failed to setup SSL 2017-01-12 8:53:04 139750636693376 [Warning] SSL error: Failed to set ciphers to use It's difficult to verify at this point, but I'm fairly sure this used to work fine. Even more interesting is that ldd gives: # ldd /usr/sbin/mysqld linux-vdso.so.1 (0x7ffc393bf000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f559a013000) libaio.so.1 => /lib/x86_64-linux-gnu/libaio.so.1 (0x7f5599e11000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f5599bf7000) libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x7f5599984000) libjemalloc.so.1 => /usr/lib/x86_64-linux-gnu/libjemalloc.so.1 (0x7f559974d000) libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x7f5599513000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f559930f000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f5598f8e000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f5598c8a000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f55988ec000) /lib64/ld-linux-x86-64.so.2 (0x557e1ecbc000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f55986d5000) which does not contain any ssl/tls lib that I can see. This makes me wonder whether mariadb is being built currently without any ssl/tls support? -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mariadb-server-core-10.1 depends on: ii libaio1 0.3.110-3 ii libc6 2.24-8 ii libjemalloc13.6.0-9 ii libpcre32:8.39-2 ii libstdc++6 6.2.1-5 ii mariadb-common 10.1.20-3 ii zlib1g 1:1.2.8.dfsg-4 mariadb-server-core-10.1 recommends no packages. mariadb-server-core-10.1 suggests no packages. -- no debconf information Many thanks for your time. Matthew
Bug#787322: bcache-tools: bcache array undetected by probe and does not appear in /dev/disk/by-uuid thus breaking boot
Package: bcache-tools Version: 1.0.7-1 Severity: grave Justification: renders package unusable Dear Maintainer, This morning, due to a resume failure, I discovered my system unbootable. I have root on a bcache array and initramfs was unable to find the array by uuid. # blkid /dev/bcache0 /dev/bcache0: LABEL="ROOT" UUID="99af68b8-58f6-4329-94a8-c54fbf0e9364" TYPE="ext4" # lsblk -o NAME,MAJ:MIN,RM,SIZE,TYPE,FSTYPE,MOUNTPOINT,UUID,PARTUUID NAMEMAJ:MIN RM SIZE TYPE FSTYPE MOUNTPOINT UUID PARTUUID sda 8:00 238.5G disk ├─sda18:10 1.9G part ext4/boot 3483abf0-06d1-43bb-8982-a472d290bae7 40579936-01 ├─sda28:20 1K part 40579936-02 ├─sda58:50 14.9G part swap[SWAP] 78e5304e-d5ad-486f-b3de-fc8e0022832c 40579936-05 ├─sda68:60 14.9G part ext4/tmp 4dcf9f94-1fcd-470b-9867-222722add442 40579936-06 └─sda78:70 206.8G part bcache 81035a2f-26fc-4546-abae-90d79d2224e4 40579936-07 └─bcache0 254:00 1.8T disk ext4/ 99af68b8-58f6-4329-94a8-c54fbf0e9364 sdb 8:16 0 1.8T disk └─sdb18:17 0 1.8T part linux_raid_ 9d8dceb3-1e4d-9958-45a2-7efb6656bbff fed0dc65-01 └─md2 9:20 1.8T raid1 bcache 7ba33238-474f-4627-8654-78bf9e36049a └─bcache0 254:00 1.8T disk ext4/ 99af68b8-58f6-4329-94a8-c54fbf0e9364 sdc 8:32 0 1.8T disk └─sdc18:33 0 1.8T part linux_raid_ 9d8dceb3-1e4d-9958-45a2-7efb6656bbff 9b7690d0-01 └─md2 9:20 1.8T raid1 bcache 7ba33238-474f-4627-8654-78bf9e36049a └─bcache0 254:00 1.8T disk ext4/ 99af68b8-58f6-4329-94a8-c54fbf0e9364 Relevant entry in fstab is: UUID=99af68b8-58f6-4329-94a8-c54fbf0e9364 / ext4 errors=remount-ro 0 1 This previously worked without problem. However, I now find the bcache array missing in both /dev/disk/by-uuid and /dev/disk/by-label: # ls /dev/disk/by-uuid/ 3483abf0-06d1-43bb-8982-a472d290bae7 78e5304e-d5ad-486f-b3de-fc8e0022832c 81035a2f-26fc-4546-abae-90d79d2224e4 4dcf9f94-1fcd-470b-9867-222722add442 7ba33238-474f-4627-8654-78bf9e36049a # ls /dev/disk/by-label/ BOOT TMP Now the bcache module is correctly being added to the initramfs, and when initramfs barfs and drops me to a shell, both the underlying RAID and the bcache array are running just fine - I can directly mount and use the bcache array; i.e. it is not an issue with registration of devices in the bcache array, or missing modules or anything like that. Indeed, if in the initramfs shell I do a: # cd /dev/disk/by-uuid # ln -s ../../bcache0 99af68b8-58f6-4329-94a8-c54fbf0e9364 # exit then the system boots up normally. I therefore believe the issue is either in /lib/udev/probe-bcache or /lib/udev/rules.d/69-bcache.rules, both of which are in this package. Even when the system is fully booted, there is no correct entry in /dev/disk/by-uuid and /dev/disk/by-label (i.e. the problem is not just in initramfs). As a temporary work around, I have changed my fstab to use /dev/bcache0 rather than the UUID and set GRUB_DISABLE_LINUX_UUID=true in /etc/default/grub before running update-grub. This at least means my system can boot. Severity was chosen to be grave on the basis that this problem has stopped my system from being bootable in both normal and recovery mode, and I would guess would affect anyone using a bcache as their root. -- System Information: Debian Release: stretch/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.0.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages bcache-tools depends on: ii initramfs-tools 0.120 ii libblkid12.26.2-5 ii libc62.19-18 ii libuuid1 2.26.2-5 bcache-tools recommends no packages. bcache-tools suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#543638: which default/config file to use?
Hi Thomas,
Thanks for the report.
On Thu, Apr 21, 2011 at 12:10:29PM +0200, Thomas Pöhler wrote:
> There are 4 default/config files which are referenced:
>
> /etc/default/rabbitmq
This no longer exists.
> /etc/rabbitmq/rabbitmq.conf
This is an "old" location for the following.
> /etc/rabbitmq/rabbitmq-env.conf
>
> And in "/usr/lib/rabbitmq/bin/rabbitmq-server" additionally a
> CONFIG_FILE is specified.
Yes, but the CONFIG_FILE refers only to /etc/rabbitmq/rabbitmq.config
Basically, there are really only two config files:
1. A shell-style file, with default location
/etc/rabbitmq/rabbitmq-env.conf
2. An erlang term file, with default location
/etc/rabbitmq/rabbitmq.config
The latter is, for various erlang reasons, referred to without the
extension.
Whilst /etc/default/rabbitmq did used to exist, it doesn't seem to now -
indeed I can only find a reference to it in postrm, and indeed
dpkg -c /home/matthew/Download/rabbitmq-server_2.4.1-1_all.deb \
| grep default
returns no results.
> The Configfile is sourced this way (correct me if im wrong)
>
> /etc/init.d/rabbitmq-server -> /usr/lib/rabbitmq/bin/rabbitmq-server
> -> /usr/lib/rabbitmq/bin/rabbitmq-env ->
> /etc/rabbitmq/rabbitmq-env.conf
Well that'll refer to (1) above, but yes, that looks right to me.
> The Problem about this is, that I can't define INIT_LOG_DIR in a
> defaults/config file because this must be set in roots environment,
> but start_rabbitmq() is run in a new session, so setting INIT_LOG_DIR
> in /etc/rabbitmq/rabbitmq-env.conf is not recognized.
>
> The only way right now is to edit the init script, which is set back
> to default with every update :(
Indeed. The problem can be put a bit more concisely as: the
rabbitmq-env.conf file is not sourced prior to the call to
setsid sh -c "$DAEMON > ${INIT_LOG_DIR}/startup_log \
2> ${INIT_LOG_DIR}/startup_err" &
in the init script.
To be fair, we never say that you should be able to configure the
INIT_LOG_DIR in the rabbitmq-env.conf file, although equally,
http://www.rabbitmq.com/man/rabbitmq-env.conf.5.man.html gets no where
near documenting everything that can be configured in the -env.conf
file.
I agree this is a bug though and I shall file a bug in our own bugzilla
to try and get this fixed.
Best wishes,
Matthew
signature.asc
Description: Digital signature
Bug#620799: rabbitmq-server: fails to purge - command (deluser|adduser) in postrm not found
On Mon, Apr 04, 2011 at 11:31:33AM +0200, Holger Levsen wrote: > The fix should at least partly be easy: your package is using adduser or > deluser from the adduser package, which is only priority important. Using > useradd or userdel from the passwd package should fix this problem. Erm, passwd is not essential, so I don't see how this helps. Both adduser and passwd are both marked important only. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#535934: xserver-xorg-core: no input devices found
This bug is bogus. It's actually caused by the recent breakage in dbus: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537125 Upgrading to a fixed version of dbus, and suddenly everything works again. At least for me. Matthew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#535934: xserver-xorg-core: no input devices found
Package: xserver-xorg-core Severity: normal I have exactly the same problem, but with version 2:1.6.2-1 as well as version 2:1.6.1.901-2. Have just spent an hour or so forcing downgrades to 1.4, but at least I have X working again now. -- Package-specific info: Contents of /var/lib/x11/X.roster: xserver-xorg /var/lib/x11/X.md5sum does not exist. X server symlink status: lrwxrwxrwx 1 root root 13 2009-07-16 12:33 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 1901168 2009-02-20 17:14 /usr/bin/Xorg Contents of /var/lib/x11/xorg.conf.roster: xserver-xorg VGA-compatible devices on PCI bus: 01:00.0 VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 3600 Series /etc/X11/xorg.conf does not exist. Xorg X server log files on system: -rw-r--r-- 1 root root 53661 2009-07-16 12:53 /var/log/Xorg.0.log Contents of most recent Xorg X server log file /var/log/Xorg.0.log: X.Org X Server 1.4.2 Release Date: 11 June 2008 X Protocol Version 11, Revision 0 Build Operating System: Linux Debian (xorg-server 2:1.4.2-11) Current Operating System: Linux koba 2.6.30-1-amd64 #1 SMP Wed Jul 8 12:20:34 UTC 2009 x86_64 Build Date: 20 February 2009 04:53:05PM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Thu Jul 16 12:51:55 2009 (EE) Unable to locate/open config file (II) Loader magic: 0x7c31c0 (II) Module ABI versions: X.Org ANSI C Emulation: 0.3 X.Org Video Driver: 2.0 X.Org XInput driver : 2.0 X.Org Server Extension : 0.3 X.Org Font Renderer : 0.5 (II) Loader running on linux (II) LoadModule: "pcidata" (II) Loading /usr/lib/xorg/modules//libpcidata.so (II) Module pcidata: vendor="X.Org Foundation" compiled for 1.4.2, module version = 1.0.0 ABI class: X.Org Video Driver, version 2.0 (--) using VT number 7 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,29e0 card 1043,8295 rev 01 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,29e1 card , rev 01 class 06,04,00 hdr 01 (II) PCI: 00:1a:0: chip 8086,2937 card 1043,8277 rev 02 class 0c,03,00 hdr 80 (II) PCI: 00:1a:1: chip 8086,2938 card 1043,8277 rev 02 class 0c,03,00 hdr 00 (II) PCI: 00:1a:2: chip 8086,2939 card 1043,8277 rev 02 class 0c,03,00 hdr 00 (II) PCI: 00:1a:7: chip 8086,293c card 1043,8277 rev 02 class 0c,03,20 hdr 00 (II) PCI: 00:1b:0: chip 8086,293e card 1043,8277 rev 02 class 04,03,00 hdr 00 (II) PCI: 00:1c:0: chip 8086,2940 card , rev 02 class 06,04,00 hdr 81 (II) PCI: 00:1c:4: chip 8086,2948 card , rev 02 class 06,04,00 hdr 81 (II) PCI: 00:1c:5: chip 8086,294a card , rev 02 class 06,04,00 hdr 81 (II) PCI: 00:1d:0: chip 8086,2934 card 1043,8277 rev 02 class 0c,03,00 hdr 80 (II) PCI: 00:1d:1: chip 8086,2935 card 1043,8277 rev 02 class 0c,03,00 hdr 00 (II) PCI: 00:1d:2: chip 8086,2936 card 1043,8277 rev 02 class 0c,03,00 hdr 00 (II) PCI: 00:1d:7: chip 8086,293a card 1043,8277 rev 02 class 0c,03,20 hdr 00 (II) PCI: 00:1e:0: chip 8086,244e card , rev 92 class 06,04,01 hdr 01 (II) PCI: 00:1f:0: chip 8086,2916 card 1043,8277 rev 02 class 06,01,00 hdr 80 (II) PCI: 00:1f:2: chip 8086,2920 card 1043,8277 rev 02 class 01,01,8f hdr 00 (II) PCI: 00:1f:3: chip 8086,2930 card 1043,8277 rev 02 class 0c,05,00 hdr 00 (II) PCI: 00:1f:5: chip 8086,2926 card 1043,8277 rev 02 class 01,01,85 hdr 00 (II) PCI: 01:00:0: chip 1002,9598 card 1043,01e4 rev 00 class 03,00,00 hdr 80 (II) PCI: 01:00:1: chip 1002,aa20 card 1043,aa20 rev 00 class 04,03,00 hdr 80 (II) PCI: 02:00:0: chip 11ab,4364 card 1043,81f8 rev 12 class 02,00,00 hdr 00 (II) PCI: 03:00:0: chip 197b,2363 card 1043,824f rev 03 class 01,06,01 hdr 80 (II) PCI: 03:00:1: chip 197b,2363 card 1043,824f rev 03 class 01,01,85 hdr 00 (II) PCI: 05:03:0: chip 11c1,5811 card 1043,8294 rev 70 class 0c,00,10 hdr 00 (II) PCI: 05:04:0: chip 10ec,8167 card 1043,820d rev 10 class 02,00,00 hdr 00 (II) PCI: End of PCI scan (II) Intel Bridge workaround enabled (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,5), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x - 0x (0x1) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x - 0x (0x1) MX[B] (II) PCI-to-PCI bridge: (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x000a (VGA_EN is set) (II) Bus 1 I/O range: [0] -1 0 0xb000 - 0xbfff (0x1000) IX[B] (II) Bus 1 non-prefetchable memory range: [0] -1 0 0xfe80 - 0xfe8f (0x10) MX[B] (II) Bus 1 prefetchable memory range:
Bug#529512: erlang-nox: Missing dependency on erlang-os-mon?
On Tue, May 19, 2009 at 11:27:54PM +0400, Sergei Golovan wrote: > On Tue, May 19, 2009 at 10:35 PM, Matthew Sackman > wrote: > > > > It seems odd, given the other dependencies of -x11 and -nox that -os-mon is > > apparently the odd one out and isn't depended on by anything. > > True. Given that erlang-os-mon uses graphical subsystem I removed it > from erlang-nox dependencies but forgot to add it to erlang-x11 > dependencies. I'll do that in the next upload. I may have missed something, but I honestly can't see anything in os-mon that is at all graphical. What do you think is in there that requires X? Cheers, Matthew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#529512: erlang-nox: Missing dependency on erlang-os-mon?
Package: erlang-nox Version: 1:13.b-dfsg1-1 Severity: normal It seems odd, given the other dependencies of -x11 and -nox that -os-mon is apparently the odd one out and isn't depended on by anything. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages erlang-nox depends on: ii erlang-asn1 1:13.b-dfsg1-1 Erlang/OTP modules for ASN.1 suppo ii erlang-base 1:13.b-dfsg1-1 Erlang/OTP virtual machine and bas ii erlang-corba 1:13.b-dfsg1-1 Erlang/OTP applications for CORBA ii erlang-crypto 1:13.b-dfsg1-1 Erlang/OTP cryprographic modules ii erlang-docbuilder 1:13.b-dfsg1-1 Erlang/OTP application for buildin ii erlang-edoc 1:13.b-dfsg1-1 Erlang/OTP module for generating d ii erlang-eunit 1:13.b-dfsg1-1 Erlang/OTP module for unit testing ii erlang-ic 1:13.b-dfsg1-1 Erlang/OTP IDL compiler ii erlang-inets 1:13.b-dfsg1-1 Erlang/OTP Internet clients and se ii erlang-inviso 1:13.b-dfsg1-1 Erlang/OTP trace tool ii erlang-mnesia 1:13.b-dfsg1-1 Erlang/OTP distributed relational/ ii erlang-odbc 1:13.b-dfsg1-1 Erlang/OTP interface to SQL databa ii erlang-parsetools 1:13.b-dfsg1-1 Erlang/OTP parsing tools ii erlang-percept1:13.b-dfsg1-1 Erlang/OTP concurrency profiling t ii erlang-public-key 1:13.b-dfsg1-1 Erlang/OTP public key infrastructu ii erlang-runtime-tools 1:13.b-dfsg1-1 Erlang/OTP runtime tracing/debuggi ii erlang-snmp 1:13.b-dfsg1-1 Erlang/OTP SNMP applications ii erlang-ssh1:13.b-dfsg1-1 Erlang/OTP implementation of SSH p ii erlang-ssl1:13.b-dfsg1-1 Erlang/OTP implementation of SSL ii erlang-syntax-tools 1:13.b-dfsg1-1 Erlang/OTP modules for handling ab ii erlang-xmerl 1:13.b-dfsg1-1 Erlang/OTP XML tools erlang-nox recommends no packages. Versions of packages erlang-nox suggests: ii erlang1:13.b-dfsg1-1 Concurrent, real-time, distributed ii erlang-doc-html 1:13.b-dfsg1-1 Erlang/OTP HTML documentation ii erlang-manpages 1:13.b-1 Erlang/OTP manual pages ii erlang-x111:13.b-dfsg1-1 Erlang/OTP applications that requi -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#500888: linux-image-2.6.26-1-vserver-amd64: cannot specify lo as non 127.0.0.1 in vserver guests
Package: linux-image-2.6.26-1-vserver-amd64 Version: 2.6.26-6 Severity: important Each of my vserver guests has a separate loopback interface. This is specified as normal in /etc/vserver/$guest/interfaces/. For example, I have: .../1/dev is "lo" .../1/ip is "127.32.0.1" .../1/prefix is "8" Under 2.6.22-3-vserver-amd64 (and earlier), this all worked fine. Under 2.6.26-1-vserver-amd64 this does not work: every vserver guest is started with lo as 127.0.0.1, thus breaking the internal network badly. -- Package-specific info: -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-3-vserver-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages linux-image-2.6.26-1-vserver-amd64 depends on: ii debconf [debconf-2.0] 1.5.23 Debian configuration management sy ii initramfs-tools [linux-initra 0.92l tools for generating an initramfs ii module-init-tools 3.4-1 tools for managing Linux kernel mo Versions of packages linux-image-2.6.26-1-vserver-amd64 recommends: ii util-vserver0.30.216~r2772-2 user-space tools for Linux-VServer Versions of packages linux-image-2.6.26-1-vserver-amd64 suggests: ii grub 0.97-47GRand Unified Bootloader (Legacy v pn linux-doc-2.6.26 (no description available) -- debconf information: linux-image-2.6.26-1-vserver-amd64/postinst/old-system-map-link-2.6.26-1-vserver-amd64: true shared/kernel-image/really-run-bootloader: true linux-image-2.6.26-1-vserver-amd64/postinst/bootloader-error-2.6.26-1-vserver-amd64: linux-image-2.6.26-1-vserver-amd64/prerm/removing-running-kernel-2.6.26-1-vserver-amd64: true linux-image-2.6.26-1-vserver-amd64/preinst/abort-overwrite-2.6.26-1-vserver-amd64: linux-image-2.6.26-1-vserver-amd64/preinst/abort-install-2.6.26-1-vserver-amd64: linux-image-2.6.26-1-vserver-amd64/preinst/lilo-has-ramdisk: linux-image-2.6.26-1-vserver-amd64/postinst/create-kimage-link-2.6.26-1-vserver-amd64: true linux-image-2.6.26-1-vserver-amd64/preinst/failed-to-move-modules-2.6.26-1-vserver-amd64: linux-image-2.6.26-1-vserver-amd64/preinst/initrd-2.6.26-1-vserver-amd64: linux-image-2.6.26-1-vserver-amd64/postinst/kimage-is-a-directory: linux-image-2.6.26-1-vserver-amd64/postinst/depmod-error-2.6.26-1-vserver-amd64: false linux-image-2.6.26-1-vserver-amd64/prerm/would-invalidate-boot-loader-2.6.26-1-vserver-amd64: true linux-image-2.6.26-1-vserver-amd64/postinst/old-initrd-link-2.6.26-1-vserver-amd64: true linux-image-2.6.26-1-vserver-amd64/preinst/elilo-initrd-2.6.26-1-vserver-amd64: true linux-image-2.6.26-1-vserver-amd64/postinst/bootloader-test-error-2.6.26-1-vserver-amd64: linux-image-2.6.26-1-vserver-amd64/postinst/depmod-error-initrd-2.6.26-1-vserver-amd64: false linux-image-2.6.26-1-vserver-amd64/preinst/overwriting-modules-2.6.26-1-vserver-amd64: true linux-image-2.6.26-1-vserver-amd64/preinst/bootloader-initrd-2.6.26-1-vserver-amd64: true linux-image-2.6.26-1-vserver-amd64/preinst/lilo-initrd-2.6.26-1-vserver-amd64: true linux-image-2.6.26-1-vserver-amd64/postinst/old-dir-initrd-link-2.6.26-1-vserver-amd64: true -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#435125: mount: dependency on nfs-common brings in portmap
Package: mount Version: 2.13~rc2-3 Severity: important mount now depends on nfs-common, and that brings in portmap, which is a potential security risk, and which I feel I should be able to explicitly remove. The mount changelog states: util-linux (2.13~rc1-2) experimental; urgency=low * A little more kfreebsd cleanup * Fix nfs-common dependency But it would seem that this "fix" has regressed in the latest version (2.13~rc2-3). Would the existence of a separate mount.nfs be possible? And could the dependency on nfs-common be removed? Many thanks, Matthew -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.21-2-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages mount depends on: ii libblkid11.40.2-1block device id library ii libc62.6-4 GNU C Library: Shared libraries ii libselinux1 2.0.15-2+b1 SELinux shared libraries ii libuuid1 1.40.2-1universally unique id library ii nfs-common 1:1.1.0-13 NFS support files common to client mount recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#390126: initscripts: breaks chroots and vservers
Hi, I've just suffered this same issue with my vservers breaking. The problem is your use of mount -n --bind / /.root By default, vservers have no capabilities and so this call fails with "Permission denied". The only solution I came across was to restart the vserver with CAP_SYS_ADMIN so that the mount call would succeed. Doing this makes the vserver about as insecure as a normal non-vserver based system. It's problematic though because it order to give it the capability, you have to restart the vserver and with the initscripts in chaos at the time, it's slightly worrying... # # Create /var/run and /var/lock on the root partition to make sure # they are available if RAMRUN or RAMLOCK is enabled. # if dpkg --compare-versions "$PREV_VER" lt "2.86.ds1-22" then # We need to quickly bind / to another location so we can make # them # just in case /var is a mountpoint or a symlink to one. mkdir /.root mount -n --bind / /.root mkdir -p /.root/var/run /.root/var/lock umount /.root rmdir /.root fi Is there anyway of achieving this without the use of mount? The other problem is that having died at the mount call, you then have to work out to rm -rf /.root before you can try reinstalling. Ideally, if you really need mount to work, you should check for the presence of the necessary capability and exit cleanly (preinit?). Cheers, Matthew -- Matthew Sackman BOFH excuse #68: only available on a need to know basis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
