i m using slackware13 destro. i want to intsall a network printer which is on window machine. but unable to connect to it. how i do this?
please help

are you gonna tell us which printer ?

i think depending on model it mite be impossible if there isnt a linux driver. however since it is hooked up (and i assume working) on a windows machine then maybe there is some sort of windows print server that must be configured ?

If you have that printer connected to a router or a switch life gets easy... well, easier.

I've found over the years that a network printer (it is an Ethernet interface, right?) is much easier to deal with if you set it with a fixed-IP address (you typically do that in the printer menu). Then your various servers can print to it without bothering each other and you pretty much don't need a dedicated print server. Just give it an IP address that's below the typical starting address of DHCP (usually xxx.xxx.x.100; you'd use xxx.xxx.x.10 or something).

On the Windows side of the world, simply set the address of the printer in the printer setup. On the Linux side of the world, you'd use CUPS and you'd set the fixed-IP address there. If it's an H-P printer, life is good because you set the printer up using HPLIP (which goes and finds it for you). If it's not an H-P printer, well, hopefully CUPS already knows about it or you have a CD-ROM with PPD files on it for the printer.

In my own systems, I have an H-P Business Inkjet 2280tn that has an entry in /etc/hosts that looks like this:
and lp and CUPS and all applications from three servers happily talk to it that way.

Now, if you said "network" but didn't mean "Ethernet," well that's different -- you'll need a dedicated printer server (probably the Linux box with Samba to support the Windows box).

Hope this helps some.

Actually, if the printer is attached to the Windows machine, CUPS should be able to handle that, as well.

Not to hijack the thread, but tronayne, do CUPS and hplip get along? I recently started the hp monitor app (with the intention of just looking, but it seems to have inserted itself in my xfce startup) and printing has never been the same. I know, I know, "If it ain't broke..." But, is it an either/or or can they both just get along. And how?

Thanks,
Geoff.

Heck yes they do!

You, either logged in as root or with su -, execute hp-setup. It's used to locate and configure for your H-P printer -- and it does all the entries and setup in CUPS while it's at it.

It's almost too easy.

If I were going to use hp-setup with an existing printer (known to CUPS) I would open the CUPS web interface and delete the printer then run hp-setup. After that, I'd open the CUPS web interface and set that printer to system default (if I wanted to be the default) and all things become simple; e.g., you can lp file and it automagically goes to the default printer set in CUPS.

The HP Status Service (that gets placed on your panel by hp-setup -- but not on the root panel if you used KDE logged in as root) lets you fiddle with the printer(s), change settings for printing photos and the like, checks ink levels and all that. Kinda nice.

Am I a happy camper? Oh, yeah.

Hope this helps some.

1 members found this post helpful.

Tronayne, I tried the uninstall, reinstall via hp-setup routine and it's still no-go. CUPS reports "/usr/lib64/cups/backend/hp failed" so I'm wondering if I have to reinstall CUPS?

Uhboy,
Geoff.

Um, that's not a lot to go on, but let's see if maybe where there's a will there's a way. You should not need to reinstall CUPS as far as I know, although you may need to upgrade the Ghostscript package if you haven't applied patches -- Ghostscript should be at ghostscript-9.02.

If your installed Ghostscript is not at that version, you could (assuming you're at Slackware-64 13.37, otherwise adjust for your Slackware version below)
and upgradepkg.

Might be a good idea to go to http://localhost:631/, then select the Printers tab and see what printer(s) you actually have defined; you can click a printer name and delete it using the Administration drop-down. It's sometimes easier to simply get rid of a printer description and start over than to try to fix something if it's been fiddled with too much. If you choose to do this, be sure to exit CUPS when you're done.

After that, you can execute hp-setup and add your printer, being sure to give it an easy-to-type name (like "DeskJet," "InkJet," "PhotoSmart" or something similar) as you go. Once that's done, simply reconnect to CUPS with http://localhost:631/printers/InkJet, select the printer, select Set as Server Default from the Administration tab and you ought to be good to go.

If you're still having problems, might be useful to mention which Slackware version you're using, what your printer model is, stuff like that, eh?

Hope this helps some.

Oh, _fine_, I'll spill the beans.

I think the problem is deeper than, and possibly unrelated to, CUPS. I've got slack_64, 13.37, running on an HP laptop (AMD Turion II, 4GB Ram). I've kept up w/ security releases, using slackpkg. I've also been installing packages like they're going out of style (you starting to notice that smell, too?) based on wanting to edit video and audio. The problem with the printer showed up in the last few weeks, coinciding with some of the package installs, but also (at least in my mind) coinciding with my invoking the HP monitoring app. Prior to that it was strictly CUPS, with the printer installed using the 'old' CLI routine of hp-makeuri and pasting the result into CUPS. What I've got now, for print results, is a first page printing correctly, then subsequent pages looking as though the printer is trying to print the entire page in an inch or so, vertically. I recently was able to print pages correctly, but with what appeared to be microscopic page headers printing in the margin.

Did I mention I'd been installing other packages? I think there's a Python package doing some damage. But, in the meantime, there's also notices being thrown off about not being able to reach 'printer.local.' I suppose I should be giving the FQDN of the printer, no?

[Finally did some work on my own update:]When I saw the mDNS notices, I figured the printer was trying to locate a 'name' it didn't know about, so I've configured the printer to be the IP addy, rather than its network name. That seems to have worked, but the micro printing of headers is still an issue (and probably a 'package' deal).

Thanks for the hand holding, stay tuned,
Geoff.

That sounds like the Ghostscript problem -- from the Slackware ChangeLogs:
Also, although it may not matter, you might try the current version of HPLIP from http://prdownloads.sourceforge.net/h...-3.11.7.tar.gz then find the SlackBuild on your distribution media (don't have it handy right now so I can't tell you where to look), edit the version number in the SlackBuild, build it and upgradepkg. Can't hurt, might help.

Last resort, removepkg cups-1.4.6-x86_64-1 and reinstall it from your media (to, maybe, clean out any messes).

Hope this helps some.

Well, that'll teach me to only watch the security changelogs. Thanks, loads, for that, it helped a lot. There are still issues, but we're on the right track. I'd already uninstalled/reinstalled the cups package during the hplip uninstall/reinstall.

Since we got on the subject of package rebuilding, I'm wondering if you can settle some rumor/bad guess questions I have. First, the building environment, if I build using a Console window, su-ing to root, is that kosher? I seem to recall someone writing that the environment (such as PATH) for root is different under su than logging in as root. Is installing packages in this fashion a problem? Even more basic, am I screwing myself by building or compiling (via Console) under X? In that case, since I use the default configuration of Slack (booting to command-line, then invoking X), is it better to change to a blank tty and log in as root?

Thirteen years 'dabbling' in Slackware and Linux, I really should have been more attentive earlier on, now that I'm using Slack for the majority of my work on this laptop. Just knowing what I needed to know at any given time is starting to catch up with me. Thanks, tronayne, for working with me on this as we wait for the OP to return.

Regards,
Geoff.

It really doesn't make a difference if you log in as root or use su - (not just su, but su -, which "...is as if your logged in as root..."). This varies somewhat (I'm told) with BASH, which I do not use in favor of KornShell; in which case, I modify by commenting-out the SU_NAME line in /etc/login.defs to obtain behavior I expect -- using su -, I get root's environment; I do not by using just su. I do prefer konsole rather than the terminal emulator in KDE.

Probably six of one.

When you install packages, particularly those built with something.SlackBuild, all the path variables are set within the SlackBuild program (shell script, if you prefer). So, all you have to do is to the installpkg as root (or su -) and all is good to go.

I violate Thou Shal't Not Work as Root directive -- I build packages from SlackBuilds.org or using src2pkg logged in as root or with su - all the time. I'm extremely careful about rm -r when so doing and I haven't had any problems since the time I wiped out an entire UNIX System 3 system in 1978 (fortunately, it was my own system so I spun the tape back on before anybody else was the wiser). I prefer to keep all package source in /usr/local/packages/src with the subdirectories defined in SlackBuilds.org; e.g., libraries, multimedia, system, etc.

When I'm doing security or performance upgrades (from Slackware), I'll usually shut the system down to single-user mode (init 1), upgradepkg whatever, then init 6. I do that with upgrades that are running daemons (like HTTPD, MySQL and the like) rather than shutting down the service, upgrading, the restarting. Just an old habit, hard to break.

Anyway, just a few thoughts -- sounds like you've got it down to the way you're comfortable with, it works for you and that's good enough, eh?

Hope this helps some.

Nah, that 'comfortable' thing is highly overrated. Rather than knowing 'enough,' I need to explore some things more fully and, again, thanks for your contribution to that effort.

The 'su -' distinction is a great one, so it's not just a typo?

As is the 'telinit 1' remark. It's not just for upgrades anymore.

Hooboy, _that_ brings me back. I, too, avoided 'rm -rf *' like the plague since learning *nix at IBM Research. What merry pranksters CompSci grads are, and being an autodidact on computers I paid attention to the danger, until I was looking to remove some material from an old laptop and realized, too late, that I was in '/' when I invoked the command. But, that occasioned a good lesson in re-creating deleted files from a Reiserfs partition.

If you're willing to continue, that whole 'package source' thing has me a little puzzled. If I compile against another path than the default /usr/src/linux, doesn't that influence how the package gets installed on another machine? Or is that merely for building and doesn't matter except to ensure a clean environment? And does that path info need to be inserted into the build script?

If we keep this up, they're gonna ask us to get our own room,
Geoff.

I tend to follow the AT&T System V "rules" (well, not really chiseled in granite, but let's say, "guidelines" instead).

System stuff, that which comes on the CD-ROM, DVD, or ISO download or 9-track, is what you've got when you do a clean install -- only the distribution software.

Stuff I add, anything I add, doesn't go in system directories. If it's, say, LibreOffice.org, it goes in /opt (you know, "optional" software). I do that with anything that's one piece, one complete application that more or less stands on its own.

If it's libraries, games (I kind of like PokerTH), library management (as in books, videos, coins, etc.) -- I kind of like Tellico, utilities, and all that stuff you just can't live without that does not come in the distribution, all of those go in /usr/local. My /usr/local tree looks the same as the system tree (well, sorta):
Note the lost+found? That's because /usr/local is a mounted file system (so's /home, /opt, /var/lib/mysql, /var/lib/virtual and /var/lib/psql.)

When I get a new release of Slackware I do a full install. When I'm doing the system setup, I declare the partitions but don't format those "local" ones; I do format the root partition, do the install and come up running with all that "local" stuff intact.

Yeah, I do copy the /etc directory off somewhere so I can get back certain settings and the like (and burn the partitions to DVD just in case), but other than that the system is brand spanking new, unsullied with any local add-on's and life is good -- takes about 20 minutes from plugging in the disk to up and running, can't complain about that.

By following that pattern on all my servers (well, four of 'em) I don't have any problems and I'm up and going quickly and easily even with a mix of two 64-bit only and two 32-bit only machines.

Building packages to install in /usr/local is not a problem. The "login" files in /etc) set /usr/local on the PATH environment and /etc/ld.so.conf sets where the linker looks for things. The LD_LIBRARY_PATH environment variable can also be used to set "non-standard" search paths.

I do not fiddle with /etc/profile (it's System! leave it be!) but I do add a custom profile in /etc/profile.d that sets certain environment variables system-wide the way I want them (one of those being for one of those "opt" things). That would be /etc/profile.d/ksh.sh because I don't use BASH and I like things the way I like them. All user accounts on my boxes are KornShell unless somebody wants a different shell (no biggie either way), and only one does (heaven only knows why but the guy like C-Shell).

What I do when build packages from SlackBuilds.org or roll my own using src2pkg is override the installation location -- when you use installpkg, you can override where the package gets installed with --root /otherroot (/ by default); I set that to /usr/local. Works just fine; dang, Slackware's got some well-thought-out stuff, eh?

Actually, you can install extra stuff on any Unix/Linux system in /usr/local and it'll be fine. If the distribution is too stupid to look in /usr/local it's child's play to simply add that to LID_LIBRARY_PATH or /etc/ld.so.conf or one or more of the /etc/profile.d files. Slackware is not too stupid, it looks there by default.

Anyway, yeah, you can do that, nope, doesn't cause problems and make system upgrades a breeze.

Hope this helps some.