Bug#434864: Problem fixed in upstream
After coordinating with the heimdal developers, I can confirm that the problem reported in this bug is apparently fixed in the upstream version heimdal-1.0.1rc4 (and not in any earlier version; specifically, not in heimdal-1.0.1rc3). -- Owen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364088: imagemagick: grab does not work
This problem was accidentally submitted twice, as bug number 364088 and as bug number 364102, because the reportbug script appeared to have failed. I suggest that bug 364088 should be merged into 364102. -- Owen Dr A O V Le Blanc [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364102: imagemagick: grab does not work
Package: imagemagick Version: 7:6.2.4.5-0.8 Severity: normal It does not seem possible to use the 'grab' function in display; it keeps creating false path names by adding x: or //, and always fails to do the grab. This used to work for me. Since grabbing is my main use for imagemagick, it makes it fairly useless for me. Dr A O V Le Blanc [EMAIL PROTECTED] -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14.2 Locale: LANG=C, LC_CTYPE=en_GB (charmap=ISO-8859-1) Versions of packages imagemagick depends on: ii libbz2-1.0 1.0.3-2 high-quality block-sorting file co ii libc62.3.6-7 GNU C Library: Shared libraries ii libfreetype6 2.1.10-1FreeType 2 font engine, shared lib ii libice6 6.9.0.dfsg.1-6 Inter-Client Exchange library ii libjasper-1.701-11.701.0-2 The JasPer JPEG-2000 runtime libra ii libjpeg626b-12 The Independent JPEG Group's JPEG ii liblcms1 1.13-1 Color management library ii libmagick9 7:6.2.4.5-0.8 Image manipulation library ii libpng12-0 1.2.8rel-5 PNG library - runtime ii libsm6 6.9.0.dfsg.1-6 X Window System Session Management ii libtiff4 3.8.2-1 Tag Image File Format (TIFF) libra ii libx11-6 6.9.0.dfsg.1-6 X Window System protocol client li ii libxext6 6.9.0.dfsg.1-6 X Window System miscellaneous exte ii libxml2 2.6.23.dfsg.2-3 GNOME XML library ii zlib1g 1:1.2.3-11 compression library - runtime imagemagick recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323746: ssh-krb5: connection aborts with protocol error: didn't expect packet type 34
On the advice of Dave Love from Daresbury, and with some extra help, we have been able to use ssh-4.2 from testing, backported to sarge, without any difficulties, and so we are replacing ssh-krb5 on all machines. Since I presume this will be the action most people will want to take, I'm willing to see this bug closed as no longer relevant. -- Owen [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295537: ipvsadm: ActiveConn reports silly numbers
I can confirm that the problem still exists with 2.6.14.2. I did not
get a reply the last time I reported the configurations, so I'm resending.
Our system uses keepalived to manage web, ssh, ftp, telnet, and rsync
connections. The web connection is by far the heaviest, with about
300 active connections at the quietest period, going up to well over
a thousand at peak times. We use direct routing, using private IP
addresses (xxx.local, 10.2.xxx). First, here is the result of
ipvsadm on a 2.4 system at the moment:
IP Virtual Server version 1.0.12 (size=4096)
Prot LocalAddress:Port Scheduler Flags
- RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP publ.mcc.ac.uk:ssh wlc
- pascal.local:ssh Route 8 1 0
- euclid.local:ssh Route 8 1 1
TCP publ.mcc.ac.uk:telnet wlc
- pascal.local:telnet Route 8 0 0
- euclid.local:telnet Route 8 0 0
TCP publ.mcc.ac.uk:ftp wlc persistent 50
- boole.local:ftp Route 8 2 51
TCP farm.mcc.ac.uk:www wlc
- zethos.local:www Route 16 79 199
- cauchy.local:www Route 8 41 112
- pliny.local:www Route 8 40 116
- thales.local:www Route 8 40 119
- kepler.local:www Route 8 41 109
- euler.local:www Route 8 42 96
- brahe.local:www Route 8 40 116
TCP jfarm.mc.man.ac.uk:www wlc
TCP farm.mcc.ac.uk:rsync wlc
- briseis.local:rsync Route 8 0 0
Then, here is ipvsadm-save:
-A -t publ.mcc.ac.uk:ssh -s wlc
-a -t publ.mcc.ac.uk:ssh -r pascal.local:ssh -g -w 8
-a -t publ.mcc.ac.uk:ssh -r euclid.local:ssh -g -w 8
-A -t publ.mcc.ac.uk:telnet -s wlc
-a -t publ.mcc.ac.uk:telnet -r pascal.local:telnet -g -w 8
-a -t publ.mcc.ac.uk:telnet -r euclid.local:telnet -g -w 8
-A -t publ.mcc.ac.uk:ftp -s wlc -p 50
-a -t publ.mcc.ac.uk:ftp -r boole.local:ftp -g -w 8
-A -t farm.mcc.ac.uk:www -s wlc
-a -t farm.mcc.ac.uk:www -r zethos.local:www -g -w 16
-a -t farm.mcc.ac.uk:www -r cauchy.local:www -g -w 8
-a -t farm.mcc.ac.uk:www -r pliny.local:www -g -w 8
-a -t farm.mcc.ac.uk:www -r thales.local:www -g -w 8
-a -t farm.mcc.ac.uk:www -r kepler.local:www -g -w 8
-a -t farm.mcc.ac.uk:www -r euler.local:www -g -w 8
-a -t farm.mcc.ac.uk:www -r brahe.local:www -g -w 8
-A -t jfarm.mc.man.ac.uk:www -s wlc
-A -t farm.mcc.ac.uk:rsync -s wlc
-a -t farm.mcc.ac.uk:rsync -r briseis.local:rsync -g -w 8
Finally, here is the keepalived.conf file:
! Configuration File for keepalived
global_defs {
notification_email {
[EMAIL PROTECTED]
}
notification_email_from [EMAIL PROTECTED]
smtp_server mailrouter.mcc.ac.uk
smtp_connect_timeout 30
lvs_id abel
}
vrrp_sync_group VG1 {
group {
VI_1
}
}
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass
}
virtual_ipaddress {
130.88.203.156
130.88.203.157
}
}
virtual_server 130.88.203.155 80 {
delay_loop 6
lb_algo wlc
lb_kind DR
protocol TCP
real_server 10.2.32.13 80 {
weight 8
TCP_CHECK {
connect_timeout 6
}
}
real_server 10.2.32.14 80 {
weight 8
TCP_CHECK {
connect_timeout 6
}
}
}
virtual_server 130.88.203.157 80 {
delay_loop 6
lb_algo wlc
lb_kind DR
protocol TCP
real_server 10.2.32.3 80 {
weight 8
TCP_CHECK {
connect_timeout 6
}
}
real_server 10.2.32.6 80 {
weight 8
TCP_CHECK {
connect_timeout 6
}
}
real_server 10.2.32.9 80 {
weight 8
TCP_CHECK {
connect_timeout 6
}
}
real_server 10.2.32.12 80 {
weight 8
TCP_CHECK {
connect_timeout 6
}
}
real_server 10.2.32.15 80 {
weight 8
TCP_CHECK {
connect_timeout 6
}
}
real_server 10.2.32.4 80 {
weight 8
TCP_CHECK {
connect_timeout 6
}
}
real_server 10.2.32.29 80 {
weight 16
TCP_CHECK {
connect_timeout 6
}
}
}
virtual_server 130.88.203.156 22 {
delay_loop 6
lb_algo wlc
lb_kind DR
protocol TCP
real_server 10.2.32.5 22 {
weight 8
TCP_CHECK {
connect_timeout 6
}
}
real_server 10.2.32.11 22 {
weight 8
TCP_CHECK {
connect_timeout 6
}
}
}
virtual_server 130.88.203.156 23 {
delay_loop 6
lb_algo wlc
lb_kind DR
protocol TCP
real_server 10.2.32.5 23 {
weight 8
TCP_CHECK {
connect_timeout 6
}
}
Bug#323746: ssh-krb5: connection aborts with protocol error: didn't expect packet type 34
On Thu, Sep 22, 2005 at 06:10:19PM -0700, Russ Allbery wrote: In my experience, this is pretty much always caused by clock skew between the systems. Have you checked the system clocks and made sure that they're within a few minutes of each other? Thanks for the suggestion, but they're all running ntp, and all within considerably less than a second of each other. I've noticed that there are some odd effects about ssh-krb5; it doesn't work as I would expect. (We have been using an older ssh, heavily patched, to support passing AFS tokens. I've tried to move to ssh-krb5 when we changed from the kaserver to heimdal recently.) In the end, I have had to give up on three machines, all of which need to have their hostnames (i.e., what you get when you give the hostname command) set to something other than the hostname; they all have more than one IP address for various reasons, and I suspect the problem may be related to this. -- Owen [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323746:
I should explain that we are using AFS, and we have recently migrated from the kaserver to heimdal, and we are trying to use ssh-krb5 to pass authentication to machines for maintenance purposes. During our testing it worked flawlessly, but for the moment in a production environment it seems to be completely unreliable. Sometimes I ssh to a machine and get pagsh, tickets, and a token; sometimes I don't. This is from the same machine on the same day with the same tickets using exactly the same command from my bash_history. Is there no explanation for why this is unreliable? Is there a way to fix this? I should also mention that I compiled the version 3.8.1p1-8 from the Debian pool, but it has the same problem with the connection aborting to the two machines in question. I can't say about the intermittent failures, since I haven't used it after discovering that it failed to correct the problem. -- Owen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323746: ssh-krb5: connection aborts with protocol error: didn't expect packet type 34
Package: ssh-krb5 Version: 3.8.1p1-7 Severity: normal -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.12.3 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages ssh-krb5 depends on: ii adduser3.63 Add and remove users and groups ii debconf1.4.30.13 Debian configuration management sy ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libcomerr2 1.37-2sarge1 common error description library ii libkrb53 1.3.6-2sarge2 MIT Kerberos runtime libraries ii libpam-runtime 0.76-22 Runtime support for the PAM librar ii libpam0g 0.76-22 Pluggable Authentication Modules l ii libssl0.9.70.9.7e-3 SSL shared libraries ii libwrap0 7.6.dbs-8 Wietse Venema's TCP wrappers libra ii zlib1g 1:1.2.2-4.sarge.2 compression library - runtime -- debconf information: ssh/privsep_tell: ssh/insecure_rshd: ssh/privsep_ask: true ssh/ssh2_keys_merged: ssh/user_environment_tell: * ssh/forward_warning: ssh/insecure_telnetd: ssh/new_config: true * ssh/use_old_init_script: true * ssh/protocol2_only: true ssh/encrypted_host_key_but_no_keygen: * ssh/run_sshd: true * ssh/SUID_client: true The problem occurs when I run ssh on a client with this package installed, trying to connect to two servers with this package installed. When I give the command 'ssh hostname', with or without various combinations of arguments, I get the response Disconnecting: Protocol error: didn't expect packet type 34 I enclose (in uuencoded gzipped tar format) the various files from /etc/pam.d/, /etc/ssh/sshd_config, /var/log/auth.log, and the result of trying ssh with the verbose option. -- Owen [EMAIL PROTECTED] begin 600 problem.tgz M'XL(`R!$,`^U;;7/;-A+VU_!78.*[B=VS9)(B)44S[IQB.XG'KVYT]YT M.BI$0A).%*`2HWUP_WVVP5(6K)E)^G4BGLE.JDE8K%88-\+B6IC+=-[F M0FNZKOGK/OSKEYKPW,;+OYK!Z_ENZX0=V,-+5.:[EMAIL PROTECTED] M7^2]CBU)[EMAIL PROTECTED])3QV#KB*I!`LTER,.N0BE5I,B$,3:5#8AZ+-YJP MVQE0D!F-)DP3/[EMAIL PROTECTED]C:K]N1K3T[OR_%8:/^C]^+OS?]SSP?R\,@@T2 M5OZ_%OW/Z+0[[X4_3Q_H8_RO]KU/_D9Q.I:C1*)*9T']X_@'?DS_S0#S MO]*`T`[EMAIL PROTECTED];I;)+=QXR`U`C-]%BF_#JN11$,[EMAIL PROTECTED] M-$G@7K-(Z8Y'8UYHH,((_.4B2K*8Q628RBF1[EMAIL PROTECTED](8_(1?4 M(HA'YEQ:@X4!$3-999$F.7IEP02A*N-)%#`FSN3:508CH8=J$K,A%PR8 M(%W$A$YI0F!)3DRDPF/YF0H4Y(I1G`-0*3F2K-IG8#P#(?3+-$HOI;`18ID [EMAIL PROTECTED])`EPV#4T5NQA*8Y+NE$T9XB*PH)!8+.O:DQC5.'KG)7J7LUPQ) M7L6]S/!;^M*%IU$94/[EMAIL PROTECTED]$^RI(,0N]?H_[OSX'_'_=_/NY_[@\S?A MN1TX%'E_]_._\$(N'2^31B_3^!F^P/WO+24:LRE;'[EMAIL PROTECTED]:KC^H[BPZ\ M0TX.NA[Y)[EMAIL PROTECTED])4AIS'%D.`3/H#N5DTIH*KJ3(! M`CJ7HT/N_BCG#4UC.DC8JH92Z=FRCRH$_.F*!#U50_!)-HT4KRZBS2+ [EMAIL PROTECTED](+$GD!.BC+75ZO/Y;OT95IIO'[EMAIL PROTECTED][EMAIL PROTECTED]S2K^ [EMAIL PROTECTED](#B8RUE=40RXM8^VV3P(J(3VP,[EMAIL PROTECTED]@9`^V(=Q6 MKDD]#-]%*'3,,AAY;/A:R)G)F+#6N6-RN'?'5LJ)O.]+QD#?DA49@EA]; MC*A39K:2*I+(:(*?@A9-_NWU8UC\LLT#M\0.M0@,[,KI@(.C4`%,(Z9`-R MA#,[EMAIL PROTECTED];R4.V6SA)[EMAIL PROTECTED])6_K+^;O_J?+P_[^Q\/]XU[_\*S[ M[DU!S07P22(BSKL#6Q3-X'[EMAIL PROTECTED];53SDIO_8*Q($%9F\1Q(F1H`? M;*H1H+=E#+6':T+D+NY:`[6Z2QVF6\Q3)[EMAIL PROTECTED];0(;A^KK)K!U M`C::*-AP(Q)D_6@$,8D_E(DB8ULY:DP7)A:)Y[6XE?``3UZ*41A/X;$J M=,2L@%600!)[EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED];;B6%H M)@I:I!/L%C[2#Q`#F:0($K.!H)V;I5.A*9Z07_8ON_O')[EMAIL PROTECTED]'^U7 MW:N/;ZR)E*46($8RR_6B!N,IW.]QJXLZ#0O2:)^5!.]AI/#]T`X+V$6-H M4%N)Z.3*MV^_/R?`\6UUG]:7I'_?5O_X-F6.7_;Y?_R.`])]_^A-D?TW5 M),_Z!$Y$$.G#`,KM1$5U:P-5P;[EMAIL PROTECTED]^,H6?OZ-B_AV!S!3K0$(6)#[J1 MYF5\%K`)T^W'X.F,-SYJMK/7NVMP)1\/%W+R[EMAIL PROTECTED]SV1CGZO_ M^'6_[W0;_E^T\/Z;Z/[EMAIL PROTECTED]:U*(#AE^F9@#IC=F=BR.P.N#* MP[EMAIL PROTECTED]/;L%C`;[EMAIL PROTECTED])MA4N8+VC.2T:-3_9!1=])JG [EMAIL PROTECTED]_V6_TI1H4F.LY6G0?:.JXKJG1RI`+)OD)^]GQ_EG M'J[(0AULQ5,+UA]VY.Z)R[A(0[EIO`0X6)N8KIG0S+$%EIB(]S)(:3NE M[T,KW;\0=IUO[EMAIL PROTECTED]@P3I3Q01X-'FC``KS9!O'YOKR:[EMAIL PROTECTED],`8) M=MT-W./:6!KCU()GW*]J)I2![8G5\'=`]4D!.B^N]O:`$T*^CXG/@/(O^S MO@/P5?[EMAIL PROTECTED];1I8=_YO!(W`Z-]M-D+/X/\@;`55_E]3 M_L_+2,F`-PBQK^'!@1FZ!OBSMH*%OM;@O8H;#$S$#/!YHC`W_((?93 MK7;(T84R@'N6OT$`($9,\,QG`N@(SX/HSZ9],\8FKR=I+$`HG?)(`ZS@ M40[)AUCRV+UCB-+8BLL`P3OUYZ8;IQG.)];Z=S_XE;-_\YY7MM_H[G?)1* M'[-YGL*L/_3'\+`_87,0,.]7MG!4C+QFJEJ_A/C4T4-C\IXIQB$S+Z-6SV M)'7C.;;CU=*62H8GEF+:)*):!.1^.,?8\T[*Z`0+0V*D'-C)DLT%VP MU0D?,LVGS!ZN^\E+`97H7A'5FQ',^`/4CN*!7(?,ERVX#.(]3-1_=5VG [EMAIL PROTECTED]:S;2:1(T`8(ZW5X`UWM.()P`'2/?3U4'^D[8-4O(T=G[U.C M6[H/[EMAIL PROTECTED],6N4,XF3')A;KNP?U,)VA;P[%0WV#GK24QD#1)S#=2Y M['67^9K'%]D`UK.B8[.;OTK`8E3Q]B[5W\?[]912;3L0A49S^0^/ICBC!U M`6[]=[HC:MQ,W9;^9\ZQS-!(R99?VD9F3O#@VUX8PC(F9%[4#BG66DT! M$E1KN;0(PFHF0-\*8CG(LRX+%EA$50[EMAIL PROTECTED]@H6KQK[J2Q'\J$1 M+3;+UBG$2[,\V)P%0PCPCC;[EMAIL PROTECTED][EMAIL PROTECTED]
Bug#295537: ipvsadm: ActiveConn reports silly numbers
On Wed Feb 16 2005 at 15:01 +. A V Le Blanc wrote: Package: ipvsadm Version: 1.24+1.21-1 I have previously been using ipvsadm with a 2.4.28 kernel. When I upgraded to 2.6.10, it appears to work, and incoming connects are distributed (using direct routing and the wlc algorithm) to the back-end machines, but the ActiveConn values don't make sense. I can confirm that this problem still exists with the 2.6.11.7 kernel. Moreover, it has been almost two months since this problem was reported, and no one has yet responded to my original bug report. Is anyone there? -- Owen Dr A V Le Blanc [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#301015: gconf2: Problem changing default keyboard layout
Package: gconf2 Version: 2.8.1-4 Severity: normal Tags: l10n -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i586) Kernel: Linux 2.6.11 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages gconf2 depends on: ii libatk1.0-0 1.8.0-4 The ATK accessibility toolkit ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libgconf2-4 2.8.1-4 GNOME configuration database syste ii libglib2.0-02.6.3-1 The GLib library of C routines ii libgtk2.0-0 2.6.2-4 The GTK+ graphical user interface ii liborbit2 1:2.10.5-0.1 libraries for ORBit2 - a CORBA ORB ii libpango1.0-0 1.8.1-1 Layout and rendering of internatio ii libpopt01.7-5lib for parsing cmdline parameters ii libxml2 2.6.16-3 GNOME XML library ii zlib1g 1:1.2.2-3compression library - runtime -- no debconf information We are using gnome on machines whose XF86Config-4 correctly specifies the keyboard layout (gb), so that if you use a different window manager and don't use gnome software, you get the correct characters when you type. But with gnome-session it overrides the XF86 configured layout and reverts to the US keyboard. Each user can of course set this using the desktop preferences - keyboard tool, but as we have a few thousand users, they find this very irritating. I have tried to override the false default by using the commands: # gconftool-2 --type string --set /desktop/gnome/peripherals/keyboard/xkb/layouts gb # gconftool-2 --type boolean --set /desktop/gnome/peripherals/keyboard/xkb/overrideSettings false But this appears to produce a further problem: when any user logs in, he gets an error message: Error activating XKB configuration. Probably internal X server problem. X server version data: The XFree86 Project, Inc 4031 You are using XFree 4.3.0. There are known problems with complex XKB configurations. Try using simpler configuration or a newer version of the XFree software. If you report this situation as a bug, please include: - The result of xprop -root | grep XKB - The result of gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb I have given these commands and obtained the following results: # xprop -root | grep XKB _XKB_RULES_NAMES_BACKUP(STRING) = xfree86, pc105, gb, , _XKB_RULES_NAMES(STRING) = xfree86, pc105, gb, , # gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb layouts = gb model = pc105 overrideSettings = false options = [] update_handlers = [] Because of this bug, we are currently discouraging users from using gnome-session. -- Owen [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
