.bloggandomene

This post is provided to you by Walter “DaK_TaLeS”, my friend. So, everytime you read “I”, it refers to him and not to me.

Just to introduce you his home-computer environment, he owns an home server/desktop hybrid system that provides SAMBA file-sharing and CUPS to export his printers to the whole family computers.
As you may already imagine, other laptops run different versions of Windows (both 32 and 64 bits).

The goal that I’ve been finally able to achieve is a smart configuration setup in order to export Windows printers drivers through CUPS service using SAMBA to share the printers onto a Windows network. This is a feature that isn’t spread out, but kind of useful.
To say it shortly, the shared printers will be available and installed on Windows systems with a simple double click, no need to Google for drivers.

It’s a kind of magic. How to do so? There’s plenty of guides around the Internet so I won’t waste bits here explaining this (you can take a look at cupsaddsmb man page for further information). As the man-page states:

cupsaddsmb exports printers to the SAMBA software (version 2.2.0 or higher) for use with Windows clients. cupsaddsmb uses the new RPC-based printing support in SAMBA 2.2.x to provide printer drivers and PPD files to Windows client machines.

In order to get through the next part of the walk-through, make sure you have SAMBA and CUPS services already installed.
Let’s configure SAMBA to provide this service by editing/adding the following lines in /etc/samba/smb.conf:

[global]
  load printers = yes
  printing = cups
  printcap name = cups

 [printers]
  comment = All Printers
  path = /var/spool/samba
  browseable = no
  public = yes
  guest ok = yes
  writable = no
  printable = yes

 [print$]
  comment = Printer Drivers
  path = /etc/samba/drivers
  browseable = yes
  guest ok = no
  read only = yes
  write list = root

Of course, you should edit your share options according to your needs.
I feel comfortable creating an user on the server and make every service run with its credentials. This makes my family happier since they don’t have to rant against annoying login popups when accessing the printers.

[global]
  map to guest = bad user
  security = share
  guest ok = yes
  guest account = winsmb

Notice that I’ve set winsmb as guest account for accessing the sharing. If you’ve chosen another username, edit the configuration above accordingly.
At this point you should be able to see the shared printers from your Windows clients, but you won’t be able to automatically fetch the drivers through the LAN.

Now go to a Windows client (it’s important that it’s running Windows 2000 or newer).
These steps need to be performed for each kind of architecture in your Home facility. If you own two or more 32-bit version of Windows, you don’t need to do that more than once. You have to perform the following tasks once for 32-bit systems and once for 64-bit system. (If you do not own one type of architecture, just ignore).

Fire up your Windows clients and go to Windows\system32\spool\drivers\w32x86\pcc\ directory (for 32 bit systems) or go to Windows\system32\spool\drivers\x64\pcc\ (for 64 bit systems). and extract the following files from a cab file:

  ps5ui.dll
  pscript.hlp
  pscript.ntf
  pscript5.dll

The cab file should be named something like “ntprint.inf__.cab” [ is supposed to be x86 or amd64 according to the Windows version; is a random value]. Extract the files above.
You should own two copies of these files: one from the Windows 32 bit, and another one from Windows 64 bit. Put the files in your USB pen-drive and return to the Dark Side of Human Being (linux).

Those files have to be copied inside two different directories so pay attention:
Copy the 32 bit files into /usr/share/cups/drivers/.
Copy the 64 bit files into /usr/share/cups/drivers/x64/.

Make sure the filenames are lower-case since Linux is case-sensitive.

Now double check you’ve done everything right. Fire up your favorite browser, head to CUPS website , and download the Windows driver (it should be named something like cups-windows-6.0-1.i386.tar, of course version could be different). Uncompress it somewhere and copy the included file

  cups6.inf
  cups6.ini
  cupsps6.dll
  cupsui6.dll

inside /usr/share/cups/drivers/. As you may notice, this driver is a 32-bit driver so you won’t be able to automagically install a printer on Windows 64-bit client system.

Here comes the part where I sweat blood and, thanks to me, you’re going to get through it smoothly.
The 64-bit driver is hosted on CUPS’s svn so you have to pick those directly from the nightly. So, go to the CUPS svn , copy all those files inside /usr/share/cups/drivers/x64/

That’s it. A piece of cake, uh?
Well, you have all what you need! cupsaddsmb needs you, temporarily, to switch to security = user; in /etc/samba/smb.conf.
Log in as root and issue cupsaddsmb -a -v (all and verbose, respectively). This command will export the driver inside the previously specified [print$] directory.
Once it terminates, let’s revert your old security thing inside smb.conf.

If you’ve chosen to create a dedicated user to the printers sharing, just add it to CUPS as authorized to print and restart CUPS service.

Well if you’ve done everything right, you’ll be able to use your printers from any kind of almost any Windows/Linux Operative system running any kind of architecture.

That’s it. Happy printing!

Well, I hope you’ve enjoyed the post. Kudos to Walter

Today just arrived the book I ordered from Amazon

It’s time to read some official resource and stop doing code&fix things.

For the fella interested in the book I bought, it’s named Beginning iPhone 3 Development: Exploring the iPhone SDK and it’s written by Jeff LaMarche and David Mark

Here’s a list of tips and tricks that I learned / discovered during these years.

eix
eix is a very simple, clean and powerful tool that allows you to perform several tasks with absolute simplicity.

• eix : it will search inside your package names. Can be parametrized in order to search in description, use regexp and so on. It’s faster than emerge and I largely prefer eix to emerge -s.

• eix-sync : Instead of using emerge —sync you can use eix-sync to synchronize portage tree and then have a brief about what changed between your previous local portage snapshot and the just fetched one. Handful.

• eix-test-obsolete: This tool is really unknown to many people. It’s very useful when you use mixed stable and testing packages on your system. Simply it checks your package.{keywords, use, mask, unmask} files/directories in order to tell you if you have something you don’t need written in there. Maybe you unmask a package, then you remove it and in package.keywords/unmask you leave an useless trace. eix-test-obsolete will tell you that.

• eix-remote: Issued with the parameter update is one of the most useful tool I’ve ever had the pleasure to see. A little prologue before. As you might know, there are a lot of “other portage tree” (or rather, overlays) that contains tons of other ebuilds that don’t fit into portage official tree. One of the most annoying thing could happen to you, is when you want to search if another ebuild has been already written or you’re force to write one yourself. The eix-remote update command will be your very best friend. It fetches a “snapshot” of the indexes of almost all the overlays in the world, and allows you to search for an ebuild just issuing eix . In order to get rid of the “remote” database, just run eix-update and your portage cache will be restored.

package.*
You should know that /etc/portage/package.{keywords,unmask,use} can be files or directories. It’s very useful having those as directories if you largely use mixed stable/testing packages.

autounmask
It’s a clean, non-perfect tool that helps you unmasking packages dependancies. How many times did you echoed a package name inside package.keywords file discovering that the package needed a dep that needed an unmasked dep that needed an unmask dep .. and so on? This tools will simplify your lives because it will add automagically the required dependancies to package.keywords. It’s really nice since it auto-recognize whether you have package.* stuff as files and directories. For instance, if your package.keywords is a directory, it will create a file named ‘autounmask-package’ containing all the required unmasked dependancies.

lafilefixer
dev-util/lafilefixer is a tool that performs a scan on your system trying to fix up broken .la files. It somehow useful when you have redundant errors regarding those files.

revdep-rebuild
app-portage/gentoolkit contains a lot of useful tools (like eclean, equery, euse) and, of course, revdep-rebuild. It’s a great tool that saved my own ass so many times. Sometimes packages breaks. Is in their nature! So, how can I fix those packages? revdep-rebuild is the one you were looking for. It will check for every dependancies (straight and reversed) discovering if some package isn’t in good health. If that happens, it will automagically re-emerge it.