Bug#940696: please add drbdtop or keep drbd-overview
On Thu, 19 Sep 2019 08:24:46 +0200 Harald Dunkel wrote: > Would it be possible to either *keep* drbd-overview (I am using it > for monitoring) or to add drbdtop to Debian? While not nearly as pleasant to work with as drbd-overview, drbdadm can produce output marginally servicable for use in crontabs, including uninitialized drbd resources. set -o pipefail /sbin/drbdadm sh-status | /usr/bin/pee \ '! /bin/grep ^_cstate | /bin/grep -v Connected' \ '! /bin/grep ^_peer | /bin/grep -v Secondary' \ '! /bin/grep ^_role | /bin/grep -v Primary' \ '! /bin/grep ^_disk | /bin/grep -v UpToDate' \ '! /bin/grep ^_pdsk | /bin/grep -v UpToDate' # /usr/bin/pee from the moreutils package
Bug#747463: [Pkg-mediawiki-devel] Bug#747463: index.php is not executable, breaking CGI
On Fri, May 09, 2014 at 09:34:47AM +0200, Thorsten Glaser wrote: On Thu, 8 May 2014, Joe Rayhawk wrote: CGI-based execution of mediawiki is made possible with chmod a+x /usr/share/mediawiki/index.php. It would be nice if this were made default so our mediawiki installations wouldn't break with every upgrade. No: ① the file has no shebang That's what binfmt-misc exists for. ② http://eindbazen.net/2012/05/php-cgi-advisory-cve-2012-1823/ I have no trust in the PHP people to keep CGI secure. I have no trust in PHP period, that's why I run it under a separate privilege level, which is why I need an external execution interface, which is why I am filing this bug. php5-cgi is a thing that is packaged for a reason; is there an actual downside to giving this executable code an execution bit? signature.asc Description: Digital signature
Bug#747463: index.php is not executable, breaking CGI
Package: mediawiki Version: 1:1.19.15+dfsg-0+deb7u1 CGI-based execution of mediawiki is made possible with chmod a+x /usr/share/mediawiki/index.php. It would be nice if this were made default so our mediawiki installations wouldn't break with every upgrade. signature.asc Description: Digital signature
Bug#549300: 5 out of 6 video cards do not work (radeon, mach64, nv, sis, mga)
Package: xserver-xorg Version: 1:7.4+4 Five out of six cards in my system aren't working properly. A similar setup (minus Matrox G400x4 and plus another TNT2) worked fine in 6.8 and 7.1. The configuration, system, and log information (because there's a lot of it) is here: http://www.omgwallhack.org/home/jrayhawk/xorgbugreport2/ Most of these problems have been present for over a year, though the problem with the AGP Radeon is less than a month old. Also new is the mercifully complete lack of kernel crashes when testing video problems. The Matrox G400x4 has always had framebuffer corruption problems, with or without the Matrox binary blob. Its behavior has not changed and should probably be disregarded for the purposes of this bug. If anyone wants more information or if I should refile this bug elsewhere, let me know. I am also willing to arrange root access and/or some sort of physical access (bringing them to the machine, or the machine to them) to trustworthy parties or folks in the Portland area. signature.asc Description: Digital signature
Bug#491036: SSL client certificates
I just fixed a firewall misconfiguration, so the above should actually work, now. GnuTLS-compiled libneon appears to be able to decrypt pkcs12, at least, so I suppose libcurl should really be able to do the same. Let me know if I should move on to bugging them about it instead. signature.asc Description: Digital signature
Bug#491036: SSL client certificate passphrase support
Package: git-core Version: 1.5.6.2-1 Severity: wishlist libcurl compiled against gnutls does not support passphrases on SSL client keys. libcurl compiled against openssl does just fine. This makes client keys rather impractical to use with Debian's git-core. Testing this can be done with the following commands: curl -O http://hitler.omgwallhack.org/ssltesting/usercert/chump.pem curl -O http://hitler.omgwallhack.org/ssltesting/testca.crt curl -O http://hitler.omgwallhack.org/ssltesting/usercert/chump-password.pem GIT_SSL_CAINFO=testca.crt GIT_SSL_CERT=chump.pem git clone https://hitler.omgwallhack.org/ssltesting/ssltest.git/ rm -rf ssltest GIT_SSL_CAINFO=testca.crt GIT_SSL_CERT=chump-password.pem git clone https://hitler.omgwallhack.org/ssltesting/ssltest.git/ rm -rf ssltest Curl, compiled against openssl, does the *right* thing: curl -E chump.pem --cacert testca.crt https://hitler.omgwallhack.org/ssltesting/ curl -E chump-password.pem:password --cacert testca.crt https://hitler.omgwallhack.org/ssltesting/ (If anyone happens to want to recreate the server environment, http://hitler.omgwallhack.org/ssltesting/ca.sh will probably help you out.) I don't know what the solution would be for this since I don't really know why git-core Depends: libcurl3-gnutls (= 7.16.2-1) in Debian in the first place. Manually replacing libcurl-gnutls.so.4.1.0 with libcurl.so.4.1.0 didn't have any other engaging consequences to git besides solving this bug for me, for what it's worth. I've tested a patch that exposes CURLOPT_SSLKEY within git. This library feature appears to do nothing in libcurl[3|4]-gnutls, so I wouldn't suggest anybody else try the same. signature.asc Description: Digital signature
Bug#489065: SSL client certificate validation
Package: lighttpd Version: 1.4.19-4 Severity: wishlist As described in the upstream tickets here: http://trac.lighttpd.net/trac/ticket/921 http://trac.lighttpd.net/trac/ticket/1288 Probably as implemented by the patch here: http://trac.lighttpd.net/trac/attachment/ticket/1288/lighty-clientvalidation-1.4.x.2.patch?format=raw signature.asc Description: Digital signature
Bug#400533: Confirmed fixed
I can confirm that this is fixed in 0.5.0. Are there any plans to package modern versions of Kazehakase? signature.asc Description: Digital signature
Bug#400533: Automated favicon.ico handling makes me want to hit things
Kazehakase's automated favicon request handling will prompt for HTTP AUTH sessions, fail to keep AUTHed HTTP connections open, and fail to cache the AUTH input. This, in combination with the Kazehakase's automated favicon request handling's failure to ever cache favicons and broken client-side page rendering behavior means that users can be prompted for AUTH input _more than once_ with _every single page_ visited. signature.asc Description: Digital signature
Bug#400533: Automated favicon.ico handling ignores RFCs, the W3, and client control.
Package: kazehakase Version: 0.4.2-1 Kazehakase's automated favicon request handling ignores network.http.max-connections-per-server constraints and has none of its own in direct violation of rfc2616 section 8.1.4. [2] Kazehakase's automated favicon request handling also overrides the standard practice of using a rel attribute defined in a profile. Kazehakase's automated favicon request handling, as an automated (or robot) user-agent, should follow robots.txt rules. Kazehakase's automated favicon request handling, as a noninteractive tranfer, cannot be interrupted by any means other than closing Kazehakase, even including attempting to stop it by closing the frame that prompted the request. Kazehakase's automated favicon request handling generates a favicon request for every page visited, regardless of whether it's been cached, isn't there, or if the page is locally generated. This results in numerous requests on XSLT (and presumably AJAX/FRAMEs/IFRAMEs/what have you, but I didn't bother testing those ones) client-side renderings, immediately guaranteeing RFC violation. Kazehakase's automated favicon request handling goes against the express wishes of the W3 to avoid HTTP request, HTTP connection, and URI namespace pollution. [1] It seems to me that childish, broken, and irresponsible features designed to let a browser run amok over the wishes of users, administrators, RFCs, and the W3 are better suited to and more characteristic of AOL. Or Firefox. [1] http://www.w3.org/2005/10/howto-favicon [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html signature.asc Description: Digital signature
Bug#378081: Cannot read V_BIOS memory allocation error -- resolved
This is working for me in the current version (1.1.1-9). I'm a very happy camper again. signature.asc Description: Digital signature
Bug#378081: Cannot read V_BIOS memory allocation error
My attempts to munge it into the current source (without knowledge of C) didn't result in a successful start. Do you still have a working source tree you can diff against? Unfortunately this looks suspiciously like a feature reversion rather than an actual bugfix. But I guess it can tide me over until the sysfs interface for this get sorted out. Assuming I can get that patch working, that is. signature.asc Description: Digital signature
Bug#378081: Cannot read V_BIOS memory allocation error
Package: xserver-xorg-core Version: 1.0.2-9 My six-card x.org configuration started failing and/or crashing during the xserver initialization with memory allocation errors on the 6.9 release and hasn't been fixed so far as I've found yet. Requesting insufficient memory window!: start: 0xd000 end: 0xdbff size 0xd88a Requesting insufficient memory window!: start: 0xdc00 end: 0xe3ff size 0xd88a (EE) R128(3): Cannot read V_BIOS Only the AGP card seems to work with the 7.0 release. The individual logs for all cards and each card, along with a lot of diagnostic information, are available (for size reasons) at http://neuroblastoma.omgwallhack.org/home/jrayhawk/xorgbugreport/ The 6.8 log is a Gentoo compile of x.org made for reference which works much the same way (as far as I can see) as Debian's 6.8 releases did. Gentoo's 6.9/7.0 packages exhibit the same broken behavior as seen here. I can provide any further information if requested. I am willing to give a trustworthy interested party root access to the machine. Just provide a SSH key and I can get that set up. signature.asc Description: Digital signature
