Hello, >> On the Linux server, are there multiple users logging into this server via >> ssh and each of them needs to print to a local printer in the way you >> mention?
Yes, there are indeed multiple users logging into the Linux server via SSH and each of them needs to print to a local printer specific to their Point of Sale (POS) activity. This is essential because it involves a POS station and a printer specifically designated for this business activity. >> Would one normally attach a printer physically to the server and your >> software talk directly to this locally attached device on the server? I am >> curious how, if you have multiple users logging in, the software would know >> which ssh session to use to communicate with the local physical printer. Indeed, it is possible to physically connect a printer to the server and the software could communicate directly with this device through a print spooler system. However, in the context of our Point of Sale (POS) environment, this approach doesn't make sense. The printer needs to be dedicated to the POS station, ensuring that the staff using the PC is as close as possible to our customers and that the printing occurs directly in front of them quickly and seamlessly. In the case of SSH sessions, each user connects to the server with their individual session streams. The printing flow is, therefore, directed through this session in a straightforward and secure manner (which is the essence of printing in passthrough mode). >> When you say ‘serial port’ as in com1:, are you referring to an old RS422 or >> RS232 serial port? Or is the device connected to a USB and has an >> association with com1 on the windows side? When I mention a "serial port" like com1:, I am indeed referring to a traditional RS422 or RS232 serial port. If the device is connected via USB and is associated with a virtual com1 port on the Windows side, it doesn't require any software modifications to handle printing in passthrough mode. From the perspective of the proprietary terminal emulator, the data flow goes through a COM port, whether it's physical or virtual. >> I recommend that you do not try and modify PuTTY or KiTTY or any of the ssh >> terminals. This will be hard to support and you may cause a security >> nightmare. We absolutely refrain from attempting to modify software such as PuTTY, KiTTY, or SSH terminal emulators ourselves. This is because it can be challenging to implement and may pose security risks. Therefore, we are actively seeking to engage with the teams behind these projects to explore potential solutions that align with our needs or we are considering proprietary alternatives >> A possible solution is to run some small glue program on both sides of the >> connection which uses a port forward tunnel. For example, on the server, a >> small program which creates a pseudo device or named socket that looks like >> a local printer. This small program reads data on the pseudo dev and copies >> it to and from a local tcp port which is forwarded over ssh. Then, on the >> windows side, you write a second small program which listens on the local >> port and copies the data to and from com1:. Essentially you are building a >> tunnel from a device or socket on the server to the com port using an ssh >> tunnel between a local and remote tcp port. I cannot say if this solution would be viable when dealing with multiple users simultaneously. I don't have the flexibility to alter the behavior of the application, and this introduces constraints that I must consider when searching for an open-source solution to meet my requirements. Of course, if I opt for proprietary solutions, I have a clear path to solving my problem. >> If you have multiple people logging into the server, you will need to find a >> way to multiply the printer port on the server. This is why I asked about >> multiple users in my first question. I would need to understand that before >> making any recommendation around that. Off the top of my head, I would >> probably have my script create a named socket for each user in >> /run/user/<uid>/foo/myprinter.sock and then in the software print to this >> socket which is unique for each user. >> Is there absolutely no way you can separate the part of your software that >> is running on the Linux server which talks bi-directionally to the printer >> and port this software to windows as a windows printer driver? Your >> situation seems a bit strange. I can’t help but think we’re missing >> something here. Developing on the Windows side for this printing functionality is not currently under consideration. Instead, the choice in this case would be to continue investing in a proprietary terminal solution, despite its cost, as it would provide more reassurance to the project team than the long-term expenses associated with maintaining this type of Windows development. Regards, Thierry
