Bug#987187: libcurl3-gnutls from debian backports breaks git http operations
hi, we still have the issue in deb10, i had to revert today to 7.64.0-4+deb10u6 for git operation to work again. Do you think there will be a patch anytime in bpo ? :) have a nice day. -- cordialement, Ghislain ADNET. AQUEOS.
Bug#1020518: [debian-mysql] Bug#1020518: Bug#1020518: libmariadb3 is a client library that include marriadb-common that will mess with /etc/mysql/my.cnf
Le 22/09/2022 à 18:37, Robie Basak a écrit : On Thu, Sep 22, 2022 at 05:28:27PM +0100, Robie Basak wrote: Again, note that I'm still speculating here because I don't follow the exact sequence of events which is causing the third party packaging to trip up here. If there's something we're doing wrong then we should fix it, but nothing I've read so far suggests that. Oh, hold on. Is the issue that you've *deleted* /etc/mysql/mariadb.cnf? If so, then yes, /usr/share/mysql-common/configure-symlinks could reasonably not call update-alternatives --install to maintain that "sysadmin choice". It should probably print a warning in this case. Sorry if i am not clear enough. in fact /etc/mysql/mariadb.cnf does not exist as there is a mysql server and not a mariadb one. I have a perconna mysql server running and i want to install mytop that require a perl lib that require libmariad3b, that then, want to replace /etc/mysql/my.cnf with a link to /etc/mysql/mariadb.cnf, but /etc/mysql/mariadb.cnf does not exist while /etc/mysql/my.cnf exist from the percona packages. hope that clarify ? sorry not native english speaker too so... -- cordialement, Ghislain ADNET. AQUEOS.
Bug#1020518: [debian-mysql] Bug#1020518: libmariadb3 is a client library that include marriadb-common that will mess with /etc/mysql/my.cnf
Le 22/09/2022 à 18:12, Robie Basak a écrit : On Thu, Sep 22, 2022 at 05:10:05PM +0200, nobody wrote: * What outcome did you expect instead? installing a client library should not require anything on the server side and should not modify server configuration of mariadb or other mysql flavors (imho ;p) Both MySQL/MariaDB client libraries and MySQL/MariaDB daemons expect and use /etc/mysql/my.cnf, and many common packages supplied by Debian link to a MySQL/MariaDB library. So Debian ends up needing to ship a working /etc/mysql/my.cnf essentially by default. It doesn't matter which side of the fork is in use - it's necessary either way. Maybe upstream could separate the two out, but they don't. thanks for your quick answer So perhaps we could see it another way : in this particular case i think that a client library, if it find an existing /etc/mysql/my.cnf, should not do anything as it is there adn so everything it need is okay. There is no need for a client library to change this part if it is here if it only need one to exist. Perhaps just adding a check if [[ ! -e /etc/mysql/my.cnf ]]; then do touch server configuration in /etc/mysql/my.cnf fi -- cordialement, Ghislain ADNET.
Bug#949622: proftpd on buster
hi, I think this is an important package to get updated in stable, or via the volatile updates repo. The one that is in stable now only works on very few clients. Hopefully the release managers agree. yes, this is not a security fix but a package that cannot be used at all is not very usefull. So i think this should be pushed in the repo for users to be able to stay in debian. Thansk for all the works of all of you ! regards, Ghislain.
Bug#949622: SSH authentication fails for many clients due to receiving of SSH_MSG_IGNORE packet
hi, As tests has been done successfully for package, and patch from proftpd for 1.3.6 and 1.3.5 have been given by upstream i wanted to know if this has been pushed to production ? :) because on my test 80% of mac/windows client seems are unable to connect to proftpd rigth now on debian 8,9 (not tested 10). regards, Ghislain.
Bug#949622: patch for 1.3.5
Hi, Tj was kind enough to make a patch for the 1.3.5 unsupported branch ! = This is for: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949622 See attached patch, generated against the 1.3.5 branch of ProFTPD in GitHub. Hope this helps, TJ proftpd-1.3.5-sftp-kbdint-packets-bug4385.patch Description: Binary data
Bug#949622: proftpd-basic: SSH authentication fails for many clients due to receiving of SSH_MSG_IGNORE packet
hi, the problem still exist for debian 9 and debian 8, is it possible to backport the patch for those versions ? regards, Ghislain.
Bug#926719: Info received (Bug#926719: SFTP ProFTPD terminating (signal 11) after Update to 1.3.5e-0+deb8u1)
hi, We are still using the old package not protected from the vulnerability, any idea when sftp on jessie will work again ? Is there anything i can do to help it ? regards, Ghislain.
Bug#926719: SFTP ProFTPD terminating (signal 11) after Update to 1.3.5e-0+deb8u1
Could you send me your sftp configuration snippet for proftpd and tell me more about your setup? How can you connect via command-line sftp but not via filezilla? i use the unmodified package with this sftp configuration SFTPEngine on AllowOverwrite on RequireValidShell off # Configure the server to listen on the normal SSH2 port, port 22 Port 2221 SFTPHostKey /etc/ssh/ssh_host_rsa_key SFTPHostKey /etc/ssh/ssh_host_dsa_key SFTPAuthorizedUserKeys file:~/.sftp/authorized_keys SFTPCompression delayed MaxLoginAttempts 6 DefaultRoot ~ Umask 0026 0027 as i said numerous customer reported issues connecting in sftp following the upgrade. We had to rollback and everything worked again. Client used where :filezilla and dreamweaver, both up to date. my command line client ( command SFTP) on ubuntu 18.04 was able to connect but not fillezilla. After rollback to previous version both client worked. The new version On debian 9 it works, but on debian 8 it fails. Ghis.
Bug#926719: dreamweaver sftp also
dreamweaver sftp client (v19.1) is also not working since the upgrade. regards, ghislain.
Bug#926719: same problem here with filezilla but not with sftp command line
hi, we got the same issue here, fillezilla worked yesterday and cannot connect since the upgrade: 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): Config for Serveur FTP : 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): SFTPEngine 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): SFTPLog 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): AllowOverwrite 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): RequireValidShell 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): SFTPHostKey 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): SFTPHostKey 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): SFTPAuthorizedUserKeys 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): SFTPCompression 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): MaxLoginAttempts 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): DefaultRoot 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): Umask 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): DirUmask 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): DefaultRoot 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): WrapEngine 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): WrapServiceName 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): WrapTables 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): WrapUserTables 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): WrapUserTables 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): DefaultRoot 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): AuthPAM 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): ROOT PRIVS at auth.c:419 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): opening TransferLog '/var/log/xferlog' 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): setting group IDs: 4733, 0, 4734 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): RELINQUISH PRIVS at auth.c:458 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): USER PRIVS 47000 at auth.c:159 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): retrieved UID 47000 for user 'admin' 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): RELINQUISH PRIVS at auth.c:164 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): Preparing to chroot to directory '/usr/local/.admin/home/admin' 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): ROOT PRIVS at auth.c:1472 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): RELINQUISH PRIVS at auth.c:1475 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): Environment successfully chroot()ed 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): ROOT PRIVS at auth.c:490 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): SETUP PRIVS at auth.c:491 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): ROOT PRIVS at auth.c:502 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): REVOKE PRIVS at auth.c:503 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0.0.0.0 (211.ip-51-68-231.eu[51.68.231.211]): changed directory to '/' 2019-04-10 10:02:59,870 .x.com proftpd[23496] 0
Bug#696926: /usr/sbin/dovecot: TCP wrapper support is needed (chroot/paravirtualized guest
Package: dovecot-core Version: 1:2.1.7-7 Followup-For: Bug #696926 Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? using fail2ban is impossible without tcpwrapper support if run in chroot or environement where iptable cannot be used. TCPwrapper is a basic security mecanism that was here on squeeze and seems to be also on sid so why not in stable ? this is really a plus to be able to stop brute fore password guessing aptempts * What exactly did you do (or not do) that was effective (or ineffective)? tested access in several config scenario, even with the fact that dovecot is uploaded with a 10-tcpwrapper.conf config file the tcpwrapper support seems missing in the binary . I tested it and got errors at server launch. * What was the outcome of this action? dovecot ignores completly hosts.deny/allow file * What outcome did you expect instead? that dovecot honors it as it do in squeeze/lenny and it seems in sid. *** End of the template - remove these lines *** -- Package-specific info: -- System Information: Debian Release: 7.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
