next »

[dbfrager]

I tried following these procedures, however, when I run system-config-printer, I do not see an option for a windows printer via samba.  the system-config-printer packages installed are:
  system-config-printer-0.7.63.4-1.fc7
  system-config-printer-libs-0.7.63.4-1.fc7

[emul8]

Hi, I went through all the steps outlined in the tutorial, and I also added a few things that were missing (foomatic-rip and ghostscript)

However, that did not work, I can see the printer and modify its settings, it has an ip address, but when I try to print a test page, it automatically stops.

Now I cannot get back into cups through the opera browser. I did not remove the password I used, I just left it in there, its my favorite password. I also tried removing the root password and then making a new one.

The screen just dissapears and then pops back up asking me for a login/pass, doesn't say what I entered was wrong, just won't let me in.

Sometimes I can get into the page, but when I try to change settings, it asks for the password.

This is really frustrating and I feel I am so close (it recognizes the printer being pluged in by the usb also, but could not test printing that way cuz passowrd does not work

Any help would be greatly appreciated.

    Thanks

[Dinky]

This may be useful to temporarily stop the requests for login / password.
Looking at  the cupsd.conf , especially the function grouping by "required user" may be helpful.  This is only a suggestion since I am not an Opera user.

Then CUPS print manager can be run by a browser:

            http://localhost:631/admin

I use the xo browser with a slightly edited /etc/cups/cupsd.conf  .
Used nano to comment out (# sign at beginning of line) any "required user" lines.    reboot !
This bypasses need for login screens, which appear to be removed on the xo.
Alternatively, printer configuration programs can be installed  or  printers.conf
can be directly edited as given in earlier posts on this topic.

Many printers will accept output from one of the CUPS built in printer drivers --
for basic printing.  In my case, the JetDirect driver using the configuration
socket://192.168.1.101:9100 works on my home wireless network.

PS.  The password problem is the cause of the printer stopping "automatically".
Before my modification of the cupsd.conf, the printer queue would start and the print job would be listed but the job would stop without printing.   This comes from the simplification (elimination of logon's) on the xo.   This is not the case with Opera -- see earlier post by Grampa.  Best of luck.

[emul8]

I took a look at the cupsd.conf file before, and thought changing DefaultAuthType from Basic to None would help, but it didn't

I also tried commenting out all the "Require user @system" and "Require user @owner"

I've also used the XO's browser but instead of giving me a login screen it just automaticaly locks me out.

I missed Grampa's statement, lifted my spirits, so I d/l it and tried to install hplip-2.8.6.run from hplip.sourcefourge.net. Was able to get all dependencies installed except libpthread, which I can't seem to figure out how to get at the moment. Seems libpthread is included in glibc, or something. Im reading up on it at the moment.


I just don't understand why I cannot login to cups from opera. The root password is correct, and it was allowing me in before. Could it have anythign to do with installing foomatic-rip and ghostscript after cups was installed? I did reinstall cups tho....

[Dinky]

One final comment  --- your comments did not mention any debug logs.  Have you tried turning on the debug line in cupsd.conf by changing  info to debug (loglevel parameter near top of file ) and viewing the more detailed log.  This gave me the clue that installing cups did not also automatically install ghostscript.  (Thus, my order of install was cups, then ghostscript).

With respect to running cups print manager, I also tried changing every  variable  in cupsd.conf (such as DefaultAuthority) but none helped.  Commenting out the four "require user" lines was finally the only changes needed to get cups to stop asking for a password (in xo browser, where any password request appears to be ignored) and complete the print test.

Edit:  I reread Tony Pearson's original article.  He used Opera, but had to set a password for user root to setup cups, then removed the password (passwd -d root) for routine use.

[Grampa]

I had this problem, but I can't remember how I solved it. According to this post:

http://olpcnews.com/forum/index.php?topic=1990.msg15754#msg15754

I set a root password before installing cups. Since you already have a root password, try deleting it, then remove cups and all of HPLIP, then set the root password again, then install cups again.

I do recall that I also had to create a debug file (it wasn't being created automatically), then I was able to isolate another problem by reading that file. I believe the other problem was that I would hit "print" from within the HP application, and nothing would happen. I think I learned that cups was not turned on, and that I had to actually run cups before I ran the HP application. I can't remember what I did to make cups run automatically, but that solved that problem.

I must have installed and uninstalled this whole system a half dozen times before I got it to work right. Good luck!

[Grampa]

Another thing to try (and this is just a wild guess) is to look at the permissions for cups:

ls -l /etc/rc.d/init.d/cups

It should look something like this:

-rwxr-xr-x 1 root root 1942 2007-11-7 13:16 /etc/rc.d/init.d cups

The "root root" tells you that the file is owned by root, and the group "root" also has permissions. The first "-" tells you its a regular file. The nine characters "rwxr-xr-x" gives you the permissions for owner, group, and others, respectively. So in this case, the owner (root) has read-write-execute permissions; the owning group and everyone else has read-execute permissions (no write).

It is possible that something has changed the permissions on the file so that it cannot be executed. I know this sort of problem occurred when I installed build 703: it broke the "su" command, even when I reverted back to build 656. I fixed it by resetting the permissions for su.

In this case, assuming that cups is the file that is giving you problems, and if the permissions do not seem right (e.g., root is not the owner, or the owner does not have execute permissions), you can fix it with the chown and chmod commands. I think it would be something like this:

chown 0:0 /etc/rc.d/init.d/cups
chmod u+s /etc/rc.d/init.d/cups

What this does is first change the ownership of cups to root:root, then set the permissions so that anyone running cups has the permissions of the owner, root.

Now please understand that I know very little about Linux, and that little bit of knowledge can be dangerous. So do this at your own risk.

Edit: It just occurred to me that you might not want SUID for this file. It might be simpler to set all the permissions to read-execute:

chmod a=rx /etc/rc.d/init.d/cups

Anyway, you get the idea. Do a little reseach on the chmod command and then try a few different alternatives.