Lpr linux to windows

Accessing Windows 7 Printer from Ubuntu Linux via LPR/LPD or Samba

I’m having difficulty printing from my Linux (Ubuntu 10.04) based PC to a printer connected to a Windows 7 machine. I was trying to connect using Samba (version 3.5.6) but this always brings up an authentication screen which never accepts any password I use. So I read somewhere that an alternative is to access the Windows printer via LPR/LPD. I added an LPR/LPD printer in Windows 7, but even within Windows 7, I am not able to print as the print que monitor shows as ‘printer busy’. The printer in question is an Epson Stylus DX7400 and works fine when using the standard USB ports. but doesn’t when I use with the LPR/LPD ports. I even opened up the TCP/IP port 515 in my McAfee firewall without any success. Any help with this would be highly appreciated. Additionally, does anyone have any idea how I can get Samba working for me?

1 Answer 1

With Samba, it looks like I finally got this solved myself. I persisted with my searches in the internet and came across a Windows 7 forum which gave the following solution which worked:-

Open Network and Sharing Centre on the Win 7 PC. Click on change advanced sharing settings. Turn off password protected sharing.

I’d already turned on file/printer sharing, but because of password protected sharing being turned on, I was having difficulty in accessing the machine on my Ubuntu machine. Now that I turned this feature off, its working with Samba.

Still not sure about the LPR/LPD option, but now that Samba is working for me. I’ll only really need to know about the LPR/LPD option out of curiosity.

Источник

SDB:Настройка сервера печати в линукс по протоколу LPD (LPR)

В статье описываются действия необходимые для превращения компьютера с линукс в сервер печати по протоколу LPD (В windows используется сокращение LPR). Предполагается что в системе уже установлен хотя бы один принтер.

Ключевые слова: linux lpd lpr сервер печать xinetd cups-lpd

Запускаем терминал в режиме суперпользователя.

Вводим пароль администратора.

Запускаем программу ‘mc’ (Midnight Commander).

Находим файл cups-lpd (полный путь /etc/xinetd.d/cups-lpd) и открываем его на редактирование.

Находим строчку где написано ‘disable = yes’, и меняем ‘yes’ на ‘no’. Сохраняем файл по клавише F2. Запускаем программу YaST.

Вводим пароль администратора.

Заходим в системные службы.

Находим службу xinetd и запускаем её c помощью [ Включить ]. В случае успешного запуска система выдаст сообщение.

Для сохранения настроек нажимаем [ Завершить ].

Подтверждаем свои намерения, через кнопку [ Да ].

Сервер печати настроен. Вводные данные для настройки принтеров на других компьютерах это IP адрес нашего сервера печати и имя очереди. В качестве имени очереди выступает имя принтера в только что настроенном сервере печати. Если в системе более одного принтера то их все имена можно использовать в качестве очередей для печати из других систем.

Произведём настройку принтера в операционной системе windows для печати на сервер печати под линукс.

Несмотря на настройку сетевого принтера выбираем ‘Локальный принтер’.

Выбираем ‘Создать новый порт’ и тип: ‘Standart TCP/IP Port’

Вводим IP адрес нашего сервера печати на линукс, в нашем случае это 192.168.0.1

Выбираем ‘Особые настройки’ и нажимаем [ Параметры ]

Выбираем протокол LPR, вводим имя очереди ‘it’ (имя очереди соответствует имени принтера предварительно настроенного в линукс). Для печати из windows обязательно ставим галочку ‘Разрешён подсчёт байт в LPR’, иначе печать может не заработать.

Выбираем производителя и модель принтера.

Выбираем драйвер принтера.

Назначаем принтеру имя, которое может и не совпадать с именем принтера в линукс.

Если нет необходимости не открываем общий доступ к принтеру из windows.

Если необходимо просим распечатать пробную страницу. Чтобы не переводить бумагу проще отказаться и напечатать тестовый лист из любого редактора поставив на чистом листе одну точку. Для базовой проверки этого вполне достаточно.

Нажимаем [ Готово ] и в системе должен появится принтер, который можно опробывать.

Если задания на печать из windows уходят, но принтер не печатает проверьте ещё раз настроки

Заходим в настройки порта.

Ещё раз проверяем, стоит ли опция ‘Разрешён подсчёт байт в LPR’.

Источник

Linux to Windows printing Gremlins

A lot can happen to a print job as it finds it’s way from client to server and then to a paper tray on a device. Even before you throw in a world class print management solution such as PaperCut, Linux to Windows printing Gremlins can hijack a print job and cause merry hell.

Printing to Windows servers from Linux using LPR

In the following example our problem is printing from Linux via LPR to a Windows based virtual print queue is causing some print jobs to go missing. The jobs go to a central find-me virtual queue, and the MFD’s are set up to look at this queue so they can release jobs, nothing unusual here. In this scenario, the stand out part of the setup that may cause issues is the cross-platform printing. Not impossible but not without its niggles.

In situations like this, a lot of thoughts will run through the heads of our support team. Jobs going missing is not by design and more than likely our first idea is to suggest (in the nicest of ways) that it’s nothing to do with PaperCut. It just so happens PaperCut is the release mechanism for these jobs, and it highlights the problem. It’s not that we are overly precious about products we sell and support, but sometimes we have to go back a step and eliminate the basics first.

Step one – Rule out PaperCut (hopefully)

Anyone that has ever sent us a printing problem support ticket will know that getting PaperCut to ignore a queue or turning off the PaperCut print provider service (the bit that does all the ugly behind the scenes tracking) is a great test to help work out where the issue is. If it is still a problem without PaperCut owning the job, then the problem could well be network, driver or device related.

In our example above we have Linux to Windows printing and “some” (not all) jobs going missing. It would be much nicer from a support POV if all jobs went missing the “some” part is the sort of thing that makes it tricky. As it only impacts some jobs, we would need to delve into some logs or ask for them if not already provided.

For strange print problems like this the minimum information we would want is as follows:
Have PaperCut debug logs, The two places to enable debug are the PaperCut Application Server and PaperCut Print Provider.

With debugging on it makes the PaperCut logs include more details that may shine a light on the problem. If it is a rare problem, then you may need to increase the amount of logs PaperCut captures. By default, modern versions of PaperCut keep up to 2048MB of log files and splits them up into 40 files roughly 50MB in size. You can see these in this folder:
C:\Program Files\PaperCut MF\server\logs

Top Tips
Be sure to use Notepad ++ to open them, other editors are available, such as: Sublime, Atom, Textedit, TextWrangler, Baretail.You can increase the size of the logs via the Admin UI under Options / Advanced, if it is a busy site and a rare issue this is well worth doing so the problem is captured in the logs and not rotated out.

Grab OS logs

There is also value in obtaining the Operating Systems print logs as well. By default, print jobs on Windows Server are not logged in the Windows Event Viewer. Why this is, I have no idea, but it can be useful when troubleshooting.
On Windows Server 2008/2012 you need to go to Event Viewer. Then click Applications and Service Logs, then find print services under Microsoft –> Windows once there click Operational and enable log. It is well worth creating a custom view and allowing all the options to be recorded.
With all of the logs above and some details around the date/time/user/print job name etc. of the support issue, we are onto a good start. These extra details assist us when looking through log files.

What to look for?

On checking any logs, you can take a look at the very top of the server.log and will see some interesting data (example below).

017-02-09 11:54:07,956 INFO AppServer:166 - Starting application server version: 16.4 (Build 39158), Edition: MF, Platform: Microsoft Windows Server 2016 Standard - 10.0 64-bit [runtime: 1.8.0_92-b14 (amd64)], User: SYSTEM [WrapperSimpleAppMain] 2017-02-09 11:54:08,003 INFO AppServer:180 - System details - max memory: 1,820.5 MB, processors: 2, database: Derby, home: "C:\Program Files\PaperCut MF\server", free space: 187,740.3 MB, hostname: PAPERCUT, IP addresses: [10.51.1.69, 10.66.66.2, fe80:0:0:0:5946:6f7:7959:13d0%eth1, fe80:0:0:0:c5bb:6897:4b3b:9065%eth2] (Primary: 10.66.66.2), Server ID: 9ae36005-cb29-4b18-80ea-18f669a8c3d4, time-zone: Europe/London, calendar: GregorianCalendar, locale: en_GB, encoding: windows-1252 [WrapperSimpleAppMain]

This tells us some important information about the setup such as version (and build), server spec, database type etc. We then use various tools to filter out the noise and check for anything obvious such as:

• Under spec server (low memory or only 1 cpu core etc)
• Are they running an old OS or version of PaperCut?
• Time-stamps in the logs out of order
• Errors and warning codes

What is the issue?

In this example, the stand out problem from the logs was the following repeated line:
PaperCut TCP/IP Port has detected that job (number) on printer “Find-me-virtual” has been resumed outside of PaperCut’s control. Printing of this job will be prevented.
This message also appears within the PaperCut Admin UI to assist in identifying problems easily.
This message tells us they are using a PaperCut TCP/IP Port and gives us the name of the queue. PaperCut has reported that something (or someone) has tried to gain control over the print job and because of this PaperCut has removed the job from the queue. It could be that a user has sufficient rights on the print queue to attempt to resume the print jobs paused in the queue. It may also be a 3rd party application such as another print management service tried to take control of the job. In this example, we are going for a different option that is causing random jobs to go missing.

PaperCut LPD to the rescue

After checking some details, we learn the customer is using the built in Windows LPD service to handle the print jobs. Using the Windows LPD service is not unusual in customers running Enterprise Linux systems that generate print jobs. LPD setups can get upset when features such as secure print release and virtual find-me queues are used.

The PaperCut Dev team developed their own LPD service to work around these idiosyncrasies, and you can read more and download it here.

The Windows LPD service has not changed much over the years which is why PaperCut created their own that is updated and supported when needed.

Running the PaperCut LPD version should solve the problem of PaperCut deleting these jobs.
We would also suggest that the virtual queue be set up to use LPT1 or a Nul port instead of using the PaperCut TCP/IP port. No print jobs should ever print from the Virtual find-me queue and the PaperCut port was designed for use with hardware checking and its just needed on the target printer queue in that instance.
Some useful links for reference:

Depending on the results of printing without PaperCut we would have also looked into the driver to see if printing using another driver or to another device brand worked ok. With any troubleshooting it is often about finding out as many facts as possible, the more context we receive, the better we can assist with fixing.

As always, if you run into problems then get in touch.

Источник