Sorry I was in a hurry in previous post so I now continue with the remaining. A. Printing. 1. PUTTY + REMOTE ANSI Printer + LPANSI was originally preferred since it makes the access and printing very easy for WAN clients. 2. The plan failed when a client try to print LARGE Print job 32-300Kbytes. The DOS Application still response but client print queue hung waiting. Example a 32Kbytes job, it receive approx 4K+ then hung. I tried various combination sometimes it send close to 8K then hung. 3. I have 4 variations of lpansi scripts/compiled program for test. Due to the way how I pipe the lpansi program for printing, I also suspect Linux PIPE SIZE setting. However, to change the setting I need to recompile the kernel, after some thought I gave up the idea. 4. OPENVPN was eventually chosen so that I can have unrestricted network access between server and WAN clients. Using CUPS setup, the large print job printed OK. 5. One printing downside is CUPS printer do not tolerate long downtime, Example: let say remote client printed some pages in application but failed to put papers in the printer, and nobody care to fix it. After some failed attempts, CUPS daemon noted the problematic status and stop the printer. When remote user later attempt to print again, the printing will have problem because the printer has been stopped on the CUPS side. Admin basically have to access CUPS page to clear jobs and restart the printer. A potential hassle for remote office with a lot of novice users and no onsite IT support, complaining about random failed printing. B. WAN considerations 1. Having WAN clients add layers of complication due to the security protection issue. This is also why I 2nd guessing on opening SSH port facing the Internet. 2. If support spending is allowed, I would honestly prefer using a vendor-supplied low-cost VPN solution and let the vendor deal with all the complication. Alternative open solutions (IPCOP/M0N0Wall) available but the VPN reading and related config issues are too numerous for me to address in a short timeframe. I may revisit them in future. -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
