Pi printserver + OMV + Webmin?

I believe my learned friend meant to type "sudo systemctl status ssh".

Ah, that seems to work (thanks Roger) and said that SSH was disabled (and highlights my fears about the errors that can easily made when typing stuff into the CLI versus exploring stuff via the GUI, although I do appreciate the power and efficiency of the CLI in the right hands). ;-)

Then I used 'sudo start service ssh' and tested aga "SSH is enabled and the default password for the 'pi' user has not been changed. This is a security risk - please login as the 'pi' user and type 'passwd' to set a new password."

Whilst I'm happy to change the password, I'm only testing this printserver and don't want to do what I have done many times before and forgotten what I changed it to after leaving it for some time and going back to it. ;-(

Cheers, T i m

Quite right, m'lud.

Clear thinking & typing was severely impacted by a nasty cough & cold with fluish overtones.

Note that just using 'sudo systemctl start ssh' will start sshd, but that it will not start automatically at the next system boot.

'sudo systemctl enable ssh' doesn't start sshd. It just just sets flags to make it start automatically at boot time.

Completing the picture. 'disable' cancels 'enable' while 'stop' stops a running daemon and 'reload' is evvectively 'stop' followed by 'start'.

Write it on a bit of paper?

I don't use the default login: I set up my own with the same name as my usual login on my other Linux machines: that way the command "login systemname" will default to the login I'm in on the other system.

If you do this, you can change the 'pi' password and happily forget what you changed it to, since you'll never need to login as 'pi' again.

On Mon, 26 Dec 2016 00:56:36 +0000, T i m declaimed the following:

If the unit is physically secure (sits on a shelf in your home, say), you could always tape the password to the top of the USB ports. Can't be any less secure than having the default password...

Ok.

Oh, ok, I've just tried that and it does so that's another box ticked (thanks). ;-)

Ok ... I think I actually followed that. ;-)

Well yes, or put it in my password doc on my PC, but I don't always bother because I 1) think I'll remember because I'm typing it in quite regularly or 2) don't think I'll come back to it so don't need to remember. I do generally note those things that are actually important. ;-)

Ok.

Ok. ;-)

What if you don't typically have 'other Linux machines'? (I do, several in fact but they are generally dual booting with Windows and only used for testing or other 'special' tasks). ;-)

Cheers, T i m

p.s. I'm working on another PC on my space upstairs so set (or thought I set) the Pi to use WiFi but with a static address. Except because I was trying to use the same i/p address as the (disconnected) wired port I don't think it was taking it, resorting to DHCP on the WiFi port (and so I couldn't access it from my other PC). What didn't help was the little yellow lightening flash that seem to be on the top right hand corner of the screen all the time, obscured the interesting bit of the IP address. Once that was sorted I seem to be back online again. ;-)

It does.

Or Dymo print the (static) IP address, username and password label and stick it to the case. ;-)

As you say, once someone has physical access to the machines all is lost anyway but I will change away from the default password, once I know it's all running etc. I leave it at default to start with because I could well end up re-installing from scratch (on a different Pi or SD card) and will have to re-remember the default password.

Cheers, T i m

I thought that might be the case, but you can set up a new user on the RPi and mutilate the Pi password ads above. The only difference is that Putty won't do the 'same user' trick. IOW here's how I get to my RPi:

- start a terminal session on this laptop (zappa) by logging in as 'myuser'. Supply the myuser.zappa password when requested.

- run the command 'ssh rpi' from myuser.zappa. This starts a terminal session on rpi under 'myuser'. Supply the myuser.rpi password when requested.

...while you'd simply login to myuser with PuTTy.

I don't use wifi at all, but would think that wifi connections would not be on the same subnet as wired connections simply because Ethernet and WiFi are using different physical ports in the RPi.

Does the new username have full access to the GUI?

Thanks,

bob prohaska

Ok, sounds complicated to me? ;-(

That sounds more like me. ;-)

Erm, well I generally set things like printers and servers with a static IP outside the DHCP scope of my FritzBox router. So, I had done that on the wired port of the Pi and when I didn't have a spare Ethernet cable I just went to WiFi. This may also be how I keep it for the Dymo printserver so that I can keep it portable (around the house). Now, I've not tried to do it for a while but I think on other OS's I might get a warning if I try to the two network ports on the same IP address (just tried doing it on W10 and it did), on the Pi it just didn't seem to 'take', no error message (that was a bit confusing at first).

Cheers, T i m

No reason why not.

My main machines run Fedora Linux and I tend to set up users for each type of task or new project. All of these come up as a graphical desktop after a local login and, because I allow X11 forwarding over ssh, after a remote login from a terminal session I can run, and GUI program I start runs normally with the GUI displayed on the remote screen.

However, running startx doesn't launch a desktop:

$ startx xauth: file /home/kiwi/.serverauth.15091 does not exist

/usr/libexec/Xorg.wrap: Only console users are allowed to run the X server xinit: giving up xinit: unable to connect to X server: Connection refused xinit: server error Couldn't get a file descriptor referring to the console $

....but I'm certain, if I could be bothered, that a configuration tweak or two would fix that.

I've be very surprised if Debian, and hence Raspbian, is significantly different.

Yup, in /etc/X11/Xwrapper.config set allowed_users=console . See the Xwrapper.config(5) manual page for more information.

Technically, no ... but you may regard this as nitpicking.

A GDI printer is the same thing as a "WinPrinter" ... it's a printer whose driver uses the same formats as the Windows Graphics Device Interface, so it's easy to write a dumb driver (for Windows) that uses GDI to build the page image in memory and then just the image to the printer as a bitmap.

From the description of what the Dymo does, that's not using GDI, it's using a proprietary Dymo format.

However, the main point is that the label image is being build up in the PC's (Pi's, in this case) memory and sent to the printer as a bitmap, which is the same idea.

Under Fedora, anyway, 'console' is the default, according to the manpage, so I tried 'anybody'. This appears to start up OK - though it appears to hang after calling 'resize' twice. If I Ctrl/C kill it at that point it reports:

xinit: unexpected signal 2 Couldn't get a file descriptor referring to the console

Just a small nitpick here - these are unix commands, useful on *any* Unix or unix-like system as long as man (and apropos) are installed. They work no matter which shell you use - they are not exclusive to bash (or any other shell). HTH

Martin Gregorie wrote:

Skipping a few label positions at the start of a job _is_ trivial if you use PostScript as (an intermediate) printer language. It's not more complex than moving to the next label position.

One could argue, though, that generating PostScript is not a trivial undertaking. :-)

I still have a script that I wrote back in 1998. It generates PostScript to print wire labels on a sheet of labels. I mainly wrote it to practice shell scripting and to play with PostScript.

Here is the start of the script:

#!/bin/sh

version="1.1"

# Version 1.0, Jun 28 1998, Kees Theunissen # Version 1.1, Jul 01 1998, Kees Theunissen # Bug fixed: t_unprintable was not used in the PostScript routine # 'next_label' to calculate the top of the printable area of a label.

# # wire_label # # Reads ascii text from stdin or specified file(s) and writes a # PostScript stream on stdout that, when printed on a sheet of labels, # writes each line of input on a separate label. The line can be # repeated several times on a label. # The layout of a sheet of labels is fully under user control and # defaults to: BRADY LASERTAB (r) MARKERS LAT-18-361 # # options: # -m All user supplied dimensions are in mm # (default: inch) # -W paperwidth Width of the sheet (default: 8.5 inch) # -H paperheight Height of the sheet (default: 11 inch) # -L left_margin Margin at left side of the sheet (left of first # column) # (default: left and right margins equal) # -T top_margin Margin at top of the sheet (above the first row) # (default: top and bottom margins equal) # -C columns Number of columns (default: 7) # -c c_spacing Spacing between columns (default: 0.1 inch) # -R rows Number of rows (default: 7) # -r r_spacing Spacing between rows (default: 0.0 inch) # -w labelwidth Width of each label (default: 1.0 inch) # -h labelheight Height of each label (default: 1.333 inch) # -t t_unprintable Unprintable area at top of label (default: 0.0 inch) # -b b_unprintable Unprintable area at bottom of label # (default: 0.833 inch) # -n lines Number of lines per label (default: 3) # -s skip Number of already used labels to skip (default: 0) # -a Argument test. Show supplied and default arguments # and exit. # filename File(s) containing the text to print (default: stdin) # < snip >

I can post the whole script if someone is interested.

Regards,

Kees.

That's exactly what I was thinking. Looking at the sheet of labels and telling the setup program where to start printing on it must be dead simple and quick to use, but writing the program that accepts your input and makes it happen always seemed to me to be quite complex, the more so as my address database and the associated label printing programs were (and are still) written with the Sculptor 4GL: it could be done but would require more effort than I was ever willing to put into it. Using labels on a one-up carrier web was and currently is the optimal solution.

If I was to write such a program now, it would probably be a Java application because Swing makes the creation of a suitable control panel so easy and the address collection would probably have become a PostgreSQL database. But this, of course, is just a reflection of the way my preferred set of developer tools has changed since the late '80s: Then I was using a mix of C and Sculptor on a Microware OS-9/68K box and these days I generally use C or Java/Postgres on Fedora Linux systems.

there used to be a library = PDFliblite - that took the sting out, but of course that's *86 only IIRC..

Hmm. Source is available...

If you stay within its limitations, which is not bad for say label printing, its very easy to use.

Only a brave man admits to using Java now Uncle Larry's legal boys after people for the unpaid Java licence fees.