All-white page on https://server:631/admin/ login #1876
Comments
|
CUPS.org User: murdie I should make it clear that I did follow the advice of the error message asking me to access the https:/... page, which is when I got the login dialogue box for the first time, and from which the problem became apparent. |
|
CUPS.org User: murdie I should also say that the same happens with backend/snmp chmod-ed 000 i.e. with the backend/snmp-induced web interface delay turned off. |
|
CUPS.org User: murdie The full error log - after I'd failed to get in as administrator - would help, now attached, though it was gathered with LogLevel info. |
|
CUPS.org User: mike What does "ls -l /lib/cups-1.2.2/etc/cups/ssl" show? |
|
CUPS.org User: murdie ls -l /lib/cups-1.2.2/etc/cups/ssltotal 8 file /lib/cups-1.2.2/etc/cups/ssl/lib/cups-1.2.2/etc/cups/ssl: directory file /lib/cups-1.2.2/etc/cups/ssl/*/lib/cups-1.2.2/etc/cups/ssl/server.crt: ASCII text ls -ld /lib/cups-1.2.2/etc/cups/ssldrwx------ 2 root lp 4096 Aug 1 11:10 /lib/cups-1.2.2/etc/cups/ssl |
|
CUPS.org User: mike What compiler are you using on the Slackware system? What version of OpenSSL? |
|
CUPS.org User: murdie
gcc-3.3.4-i486-1
openssl-0.9.7e-i486-4 |
|
CUPS.org User: mike Hmm, strange. What browser are you using? Maybe the OpenSSL stuff was compiled without all of the algorithms? |
|
CUPS.org User: murdie
Problem happens with Epiphany 1.6.4 - again, I think, from last year's Slackware build.
Umm, I wouldn't know - we've been using that (Slackware-provided) build for just coming up to a year now, without problem. I'm busying myself with some other work at the minute, but will return to look at this again as soon as I can. CUPS 1.2.2 works ok (apart from the other problems I've reported and worked around) on Solaris 8 here, so we have something useable to be getting on with. John A. Murdie |
|
CUPS.org User: cajardim I have this problem too. I use FreeBSD 4.10 and cups 1.2.2, i access https and cups is high process in top (command), the printers not respond. In error_log I [08/Aug/2006:09:54:50 -0300] Started backend /usr/local/libexec/cups/backend/socket (PID 48692) for job 47857. I restart cups process and printed is normal usage Exists some soluction to this problem ? Thanks |
|
CUPS.org User: murdie My guess is that you're seeing this problem because the snmp pseudo-backend is taking a long time to SNMP- and then IPP-probe your printers. To avoid the problem - at the cost of losing the printer auto-discovery mechanism introduced in 1.2.2 - take read/execute permission off the snmp executable, where $CUPS is the base of your CUPS installation, probably /usr/local or /usr: chmod 000 $CUPS/lib/cups/backend/snmpand then go back to the CUPS web administration page. I see the all-white page even with snmp so disabled; I'd be interested to know if this was the case for you, too. John A. Murdie |
|
CUPS.org User: mike Another possibility that was recently posted to the CUPS forums - your system might not be providing sufficient entropy to generate the server key, leading to the lockup... |
|
CUPS.org User: murdie Well, who knows - though the situation I have is similar to that described in the posting to the forums you mention. The article is "CUPS error_log entries "Generating SSL server key..." with hanging cupsd" posted by Kurt Pfeifle at 22:09 (forum time) on Monday the 14th August 2006. It refers to a blog entry by Ross Burton at http://www.burtonini.com/blog//computers/cups-2006-08-14-18-00. I now find that I can get into the CUPS administration web page without the all-white display, and that: sysctl kernel.random.entropy_availkernel.random.entropy_avail = 3585 but I don't know what this value was when I was suffering the problem. Perhaps a test should be added to the CUPS web server (?) code to test for and report the error situation to the user? John A. Murdie |
|
CUPS.org User: mike Fixed in Subversion repository. I've added a run of the "openssl rand ..." command on platforms without /dev/urandom so that the "openssl x509 ..." command doesn't block. This should cure the blank admin page issues caused by the first use of encrypted connections... |
Version: 1.2.2
CUPS.org User: murdie
Having got cups 1.2.2 working on our Solaris 8 printserver, though with a few odd problems reported elsewhere, I decided that the reason that I'd had trouble was my choice of a less-than-common operating system platform, surely most people have CUPS installed on Linux. So, I stopped the experimental CUPS scheduler on my Solaris printserver and chose a Slackware Linux 10.1 compute server (on the same subnet as the Solaris system, which is the same subnet our Linux desktop clients are on also). I then built CUPS 1.2.2 from source and installed it - taking care that none of the install overwrote anything already installed as part of the Slackware distribution (summary follows, see attached file typescript for the full story):
../configure --prefix=/lib/cups-1.2.2 --localstatedir=/var/spool/cups-1.2.2
make
-- I edited Makefile here to remove line 33, which adds PHPDIR to the list of install directories, as I didn't want to pollute our PHP installation.
make install
/etc/rc.d/init.d/cups start
cups: started scheduler.
cd /var/spool/cups-1.2.2/log/cups
cat error_log
...
All seems well. One difference from my Solaris install is that that did not build with SSL. So, when I browsed http://server:631/printers/ and clicked on the 'Start printer' button of the printer I've been using to test with (an HP LaserJet 8150dtn), I see the message:
426 Upgrade Required
You must access this page using the URL
https://server:631/admin/?op=start-printer&printer_name=printer
and a dialogue box asking me to login as the CUPS administrator. I do so by logging in as 'root' with the system's root password, and get a completely white web page. Pressing reload only gets me the dialogue box again. If I type a nonsense password, I see:
401 Unauthorized
Enter your username and password or the root password to access this page.
I can't manage the installation via the web interface!
What gives? I attach the build log of my installation.
The text was updated successfully, but these errors were encountered: