Re: [gentoo-user] Re: Sharing printers via Cups
On 2/10/2021 4:44 PM, Grant Edwards wrote: I think I probably would have just bought a printer long before this point... I guess you have money. As the old joke saying goes "I'm so broke I can't afford to pay attention." Fact is, though, that a new printer would solve nothing because at the moment all that I'm doing is in VMWare on the Win 10 box that I stated before is not mine but I have permission to use. I'm trying to get it all set for eventual transfer to real computers. And the issue I am facing is an issue I'd face no matter what. I am _NOT_ buying a printer for each computer that will be there. So it's a matter of having a printer connected to one computer and having the others connect to that first server. Great. That's just what I'm trying to accomplish! I even tried sending the job via HTTP and HTTPS. At that point the logs on Athena show a LOT of output like this: D [10/Feb/2021:17:44:46 -0700] [Client 77] Server address is "192.168.10.2". D [10/Feb/2021:17:44:46 -0700] [Client 77] Accepted from 192.168.10.3:35684 (IPv4) D [10/Feb/2021:17:44:46 -0700] [Client 77] Waiting for request. D [10/Feb/2021:17:44:46 -0700] [Client 77] POST /printers/ENVY HTTP/1.1 D [10/Feb/2021:17:44:46 -0700] cupsdSetBusyState: newbusy="Active clients", busy="Active clients" D [10/Feb/2021:17:44:46 -0700] [Client 77] Read: status=200, state=6 D [10/Feb/2021:17:44:46 -0700] [Client 77] No authentication data provided. D [10/Feb/2021:17:44:46 -0700] [Client 77] 2.0 Get-Job-Attributes 132 D [10/Feb/2021:17:44:46 -0700] Get-Job-Attributes http://athena:631/printers/ENVY D [10/Feb/2021:17:44:46 -0700] [Client 77] Returning IPP successful-ok for Get-Job-Attributes (http://athena:631/printers/ENVY) from 192.168.10.3. D [10/Feb/2021:17:44:46 -0700] [Client 77] Content-Length: 284 D [10/Feb/2021:17:44:46 -0700] [Client 77] cupsdSendHeader: code=200, type="application/ipp", auth_type=0 D [10/Feb/2021:17:44:46 -0700] [Client 77] con->http=0x561443dbc990 D [10/Feb/2021:17:44:46 -0700] [Client 77] cupsdWriteClient error=0, used=0, state=HTTP_STATE_POST_SEND, data_encoding=HTTP_ENCODING_LENGTH, data_remaining=284, response=0x561443df8940(IPP_STATE_DATA), pipe_pid=0, file=-1 D [10/Feb/2021:17:44:46 -0700] [Client 77] Writing IPP response, ipp_state=IPP_STATE_DATA, old wused=0, new wused=0 D [10/Feb/2021:17:44:46 -0700] [Client 77] bytes=0, http_state=0, data_remaining=284 D [10/Feb/2021:17:44:46 -0700] [Client 77] Flushing write buffer. D [10/Feb/2021:17:44:46 -0700] [Client 77] New state is HTTP_STATE_WAITING D [10/Feb/2021:17:44:46 -0700] [Client 77] Waiting for request. D [10/Feb/2021:17:44:46 -0700] cupsdSetBusyState: newbusy="Not busy", busy="Active clients" D [10/Feb/2021:17:44:47 -0700] [Client 77] POST /printers/ENVY HTTP/1.1 D [10/Feb/2021:17:44:47 -0700] cupsdSetBusyState: newbusy="Active clients", busy="Not busy" D [10/Feb/2021:17:44:47 -0700] [Client 77] Read: status=200, state=6 D [10/Feb/2021:17:44:47 -0700] [Client 77] No authentication data provided. D [10/Feb/2021:17:44:47 -0700] [Client 77] 2.0 Get-Printer-Attributes 133 D [10/Feb/2021:17:44:47 -0700] Get-Printer-Attributes http://athena:631/printers/ENVY D [10/Feb/2021:17:44:47 -0700] [Client 77] Returning IPP successful-ok for Get-Printer-Attributes (http://athena:631/printers/ENVY) from 192.168.10.3. D [10/Feb/2021:17:44:47 -0700] [Client 77] Content-Length: 1853 D [10/Feb/2021:17:44:47 -0700] [Client 77] cupsdSendHeader: code=200, type="application/ipp", auth_type=0 D [10/Feb/2021:17:44:47 -0700] [Client 77] con->http=0x561443dbc990 D [10/Feb/2021:17:44:47 -0700] [Client 77] cupsdWriteClient error=0, used=0, state=HTTP_STATE_POST_SEND, data_encoding=HTTP_ENCODING_LENGTH, data_remaining=1853, response=0x561443de64a0(IPP_STATE_DATA), pipe_pid=0, file=-1 D [10/Feb/2021:17:44:47 -0700] [Client 77] Writing IPP response, ipp_state=IPP_STATE_DATA, old wused=0, new wused=0 D [10/Feb/2021:17:44:47 -0700] [Client 77] bytes=0, http_state=0, data_remaining=1853 D [10/Feb/2021:17:44:47 -0700] [Client 77] Flushing write buffer. D [10/Feb/2021:17:44:47 -0700] [Client 77] New state is HTTP_STATE_WAITING D [10/Feb/2021:17:44:47 -0700] [Client 77] Waiting for request. D [10/Feb/2021:17:44:47 -0700] cupsdSetBusyState: newbusy="Not busy", busy="Active clients" D [10/Feb/2021:17:44:47 -0700] [Client 77] HTTP_STATE_WAITING Closing for error 32 (Broken pipe) D [10/Feb/2021:17:44:47 -0700] [Client 77] Closing connection. -- Dan Egli On my test server
[gentoo-user] Re: Sharing printers via Cups
On 2021-02-10, Dan Egli wrote: > On 2/10/2021 4:30 AM, Michael wrote: >> On Tuesday, 9 February 2021 19:23:41 GMT you wrote: >>> On 2/9/2021 3:20 AM, Michael wrote: > Actually tried that. Got LPD installed, sent a test page. Test page > appeared in the Windows Queue, then disappeared without any [...] > Yea, but due to the funky setup I have here, sending via IPP isn't going > to be an option. I tried that last night, and it completely refused to > work. So now I'm trying to go back to the Samba configuration. I think I probably would have just bought a printer long before this point... -- Grant
Re: [gentoo-user] Sharing printers via Cups
On 2/10/2021 4:30 AM, Michael wrote: On Tuesday, 9 February 2021 19:23:41 GMT you wrote: On 2/9/2021 3:20 AM, Michael wrote: Actually tried that. Got LPD installed, sent a test page. Test page appeared in the Windows Queue, then disappeared without any acknowledgement from the printer. This would need some troubleshooting/configuring on the Windows end. It's a long time ago I tried this and don't recall what I had configured to allow clients to print via the Windows PC. It was relatively simple and lightweight though, unlike Samba which I wouldn't bother with just for printing. If it was JUST for printing I'd agree. But the whole samba setup is for more than that. There's also file sharing (since Windows 10 home doesn't support NFS), central authentication, things like that. Ah! Fair enough. Since Samba is running you might as well use it for printing. Seems that way to me. L) I finally got it working in samba mode so I'm good with that. And that, again, would skip the whole point of having a central print server. :) Not really. Athena would remain the CUPS server for itself and any Linux or additional OS clients, sending jobs over IPP:// to the Windows print server running on the Windows PC. Okay, I could see that one. Although I'm totally lost when it comes to IPP. I've looked but apparently my google-fu is still weak because I can't find any good documentation on how to setup IPP, how to format the URLs, etc I have found IPP to be straight forward, simpler than other set ups and provided by most (all?) printers on port 631. Setting it up is explained in this section: https://wiki.gentoo.org/wiki/Printing#Installing_the_printer Something like 'ipp://192.168.10.2/ipp' should work - your printer's manual would confirm what it accepts. Anyway, this is not what you're after in your use case. Yea, but due to the funky setup I have here, sending via IPP isn't going to be an option. I tried that last night, and it completely refused to work. So now I'm trying to go back to the Samba configuration. OK, I just tested it here. I ticked to share *both* the CUPS server and a laser printer. The server setting is on the right hand side of the Administration page on the GUI and the printer on the left of the page. I observed the same result like you - although CUPS started listening on port 631 for connections from LAN clients, the GUI continued to show "not shared". NOTE: I did not test printing a page from a client to see if the display on the GUI changes to say "shared". It may be a real time indication of the status of the printer - or it could indeed be a bug. "... For other systems to use the printer through IPP, explicit access to the printer must be granted in the /etc/cups/cupsd.conf file. To share the printer using SAMBA, this change is not needed." I note you're using CIDR notation for the LAN subnet, while the wiki is using a "*" wildcard instead. I don't know if it makes a difference, but anyway since you'll be using a Samba shared printer this should not be relevant. [snip ...] zSimilarly, check the "hosts allow" directive in the Samba configuration to Again, I think you're misunderstood the problem. Forget Janus for a second. Forget Samba for a minute. I create a pinter via the CUPS web interface on Athena. When it shows the box to make it shared, I check the box. When I finish and the printer status appears, it says "not shared". Other machines and other protocols have not even come into play yet. I understood you were faced with two problems, really though, one only. Printing from Janus doesn't work. Printing from the other PCs works as intended. Kind of. More like printing from the windows host works, and printing from Athena works. Printing from anywhere else does not. The "not shared" printer indication on CUPS GUI on Athena, should not be a problem affecting Janus' ability to print - I expect it is irrelevant. The Samba logs will hopefully indicate where the actual problem lies. This is how I understand the printing process ought to work in your use case: The Samba server, Athena, will use the MSWindows Network Printer identified as "Windows Printer via SAMBA" in its CUPS GUI. Printing jobs will be submitted from Athena's CUPS to the MSWindows PC & its attached printer, via the corresponding smb:// URI. CUPS which will use the Samba server on Athena to authenticate and send the data for printing to the MSWindows PC and its shared printer. The same process will need to be followed by Janus; i.e. the CUPS server on Janus will have to use the same smb:// URI to submit the data to be printed to Athena's Samba server and as long as authentication is successful Athena will forward it to the Windows PC. Forgive me, but if I use the SAME url, then it's not Athena acting as the print server, it's the windows client that the printer is hooked up to. I tried to use the LPD to print to Athena and have Athena print to the printer via Samba. That's
[gentoo-user] Re: xf86OpenConsole: Cannot open virtual console 1 (Permission denied)
On 2021-02-10, antlists wrote: > On 09/02/2021 04:44, cal wrote: >>> but it doesn't, when I log-in the XFCE4 is not starting automatically, >>> I have to type manually: startxfce4 >> >> I see you have already solved your problem. But it bears mentioning: >> .xinitrc is executed by runing `startx`, not by the login shell. > > Indeed, I don't know what "rc" at the end stands for, but if a file ends > in rc it is almost always a *config* file, which is *read* by the target > of interest. It is in no way shape or form an executable of any sort. IIRC, rc originally stood for "run commands", and it contained a list of commands for the application to run during initialization. They are almostly always not executable, but rather configuration commands in some application-specific syntax. -- Grant
Re: [gentoo-user] xf86OpenConsole: Cannot open virtual console 1 (Permission denied)
On 09/02/2021 04:44, cal wrote: but it doesn't, when I log-in the XFCE4 is not starting automatically, I have to type manually: startxfce4 I see you have already solved your problem. But it bears mentioning: .xinitrc is executed by runing `startx`, not by the login shell. Indeed, I don't know what "rc" at the end stands for, but if a file ends in rc it is almost always a *config* file, which is *read* by the target of interest. It is in no way shape or form an executable of any sort. Cheers, Wol
Re: [gentoo-user] Sharing printers via Cups
On Tuesday, 9 February 2021 19:23:41 GMT you wrote: > On 2/9/2021 3:20 AM, Michael wrote: > >> Actually tried that. Got LPD installed, sent a test page. Test page > >> appeared in the Windows Queue, then disappeared without any > >> acknowledgement from the printer. > > > > This would need some troubleshooting/configuring on the Windows end. It's > > a long time ago I tried this and don't recall what I had configured to > > allow clients to print via the Windows PC. It was relatively simple and > > lightweight though, unlike Samba which I wouldn't bother with just for > > printing. > > If it was JUST for printing I'd agree. But the whole samba setup is for > more than that. There's also file sharing (since Windows 10 home doesn't > support NFS), central authentication, things like that. Ah! Fair enough. Since Samba is running you might as well use it for printing. > >> I finally got it working in samba mode > >> so I'm good with that. And that, again, would skip the whole point of > >> having a central print server. :) > > > > Not really. Athena would remain the CUPS server for itself and any Linux > > or additional OS clients, sending jobs over IPP:// to the Windows print > > server running on the Windows PC. > > Okay, I could see that one. Although I'm totally lost when it comes to > IPP. I've looked but apparently my google-fu is still weak because I > can't find any good documentation on how to setup IPP, how to format the > URLs, etc I have found IPP to be straight forward, simpler than other set ups and provided by most (all?) printers on port 631. Setting it up is explained in this section: https://wiki.gentoo.org/wiki/Printing#Installing_the_printer Something like 'ipp://192.168.10.2/ipp' should work - your printer's manual would confirm what it accepts. Anyway, this is not what you're after in your use case. > >>> 3. If the current setup is the right thing for you, increase CUPS log > >>> verbosity and check the logs on Athena to find out what it isn't happy > >>> with > >>> when Janus sends a print job to it. First check the CUPS driver and > >>> printing protocol is the same on Janus as on Athena and the CUPS' config > >>> on Athena allows inbound connections from your LAN, or your Janus' IP > >>> address. > >> > >> I can check on those. Thanks. I do notice one thing strange. Maybe a > >> cups bug. In the web interface when I created the printer in Athena, I > >> checked the box to say it was a shared printer. But when I look at the > >> status it says "not shared". OK, I just tested it here. I ticked to share *both* the CUPS server and a laser printer. The server setting is on the right hand side of the Administration page on the GUI and the printer on the left of the page. I observed the same result like you - although CUPS started listening on port 631 for connections from LAN clients, the GUI continued to show "not shared". NOTE: I did not test printing a page from a client to see if the display on the GUI changes to say "shared". It may be a real time indication of the status of the printer - or it could indeed be a bug. > > Hmm ... what follows the commented line: > > > > # Restrict access to the server... > > > > Order Deny,Allow > > ... ? > > > > in the '/etc/cups/cupsd.conf' of Athena? > > Here's the entire file. Although I fail to see what the allow/deny could > mean for a printer showing on Athena. It's not that Janus says it's not > a shared printer. It's ATHENA saying it's not shared, right after I > checked the box to make it shared. Yes, you're right, the indication "not shared" won't change by ticking the box "shared" - I just wanted to confirm the actual configuration of the server was not restricting connections to CUPS for localhost only. However, it seems without having the same setup here, I may have given you a bum steer - my apologies: Reading the wiki page it states - https://wiki.gentoo.org/wiki/Printing#Remote_printer_access "... For other systems to use the printer through IPP, explicit access to the printer must be granted in the /etc/cups/cupsd.conf file. To share the printer using SAMBA, this change is not needed." I note you're using CIDR notation for the LAN subnet, while the wiki is using a "*" wildcard instead. I don't know if it makes a difference, but anyway since you'll be using a Samba shared printer this should not be relevant. [snip ...] > > Similarly, check the "hosts allow" directive in the Samba configuration to > > include Janus' IP address. > > Again, I think you're misunderstood the problem. Forget Janus for a > second. Forget Samba for a minute. I create a pinter via the CUPS web > interface on Athena. When it shows the box to make it shared, I check > the box. When I finish and the printer status appears, it says "not > shared". Other machines and other protocols have not even come into play > yet. I understood you were faced with two problems, really though, one only. Printing
[gentoo-user] [offtopic] mount with correct SELinux context on Android
Hi, I hope someone here can help me with the following problem on the Linux environment Termux on my Android phone. My phone has not enough storage on the /data partition but lots of free space on my external SD card (adoptable storage) which contains an extfat (sdcardfs) file system which cannot be used under Termux (Linux) except for storing plain data files. Therefore I'd like to create a (big) file - say EXT.raw - there and mount it as a loop device. Under root (tsu in Termux) this is not a problem, but I cannot access this new device as non-root user in Termux. I don't know SELinux, but I have to mount that loop device with the proper SELinux-context to make it accessible as non-root user. How can I do this (or any pointers to documentation on this). Many thanks for a hint, Helmut
Re: [gentoo-user] ruby and package.use
"Neil Bothwick" , 10.02.2021, 09:52: > On Wed, 10 Feb 2021 16:45:15 +1100, Adam Carter wrote: >> It seems like ruby regularly wants to stuff ruby_targets_rebyNN entries >> into package.use on my machines - is this normal? >> Now that ruby3 is out it wants to add a bunch of ruby_targets_ruby30 >> entries to the ruby_targets_ruby27 crud that's already there. > Same here. When this happens, I delete /etc/portage/package.use/ruby and > let portage create a fresh one. > It's still a mess, just a slightly cleaner and up to date mess. When a bunch of these pop up, I usually add that ruby version to RUBY_TARGETS in /etc/portage/make.conf and restart the emerge. s.
Re: [gentoo-user] ruby and package.use
On Wed, 10 Feb 2021 16:45:15 +1100, Adam Carter wrote: > It seems like ruby regularly wants to stuff ruby_targets_rebyNN entries > into package.use on my machines - is this normal? > > Now that ruby3 is out it wants to add a bunch of ruby_targets_ruby30 > entries to the ruby_targets_ruby27 crud that's already there. Same here. When this happens, I delete /etc/portage/package.use/ruby and let portage create a fresh one. It's still a mess, just a slightly cleaner and up to date mess. -- Neil Bothwick "Everything takes longer than expected, even when you take into account Hoffstead's Law." - Hoffstead's Law pgppHDBb99RDM.pgp Description: OpenPGP digital signature
