On Tue, 30 Aug 2022 at 12:59, gene heskett <gheskett@shentel.net> wrote:

But that might create another problem. how to differentiate the servers,
both of which
will want to use localhost:5000 to serve up their web pages we run
things with.

Suggested solutions?

This is nothing to do with venvs, so I'm forking the thread.

By far the easiest way to differentiate them is to NOT have them both
on localhost:5000. Depending on how you invoke the servers, you should
be able to find a way to configure one (or both) of them to a
different port; common methods include a "--port" argument, setting
the PORT environment variable, and poking in the code to find the
number 5000 and changing it to some other value.

(Less common methods include poking in ctypes to find the number 5000
and changing it to some other value. Mentioned only because I realise
the alternative interpretation of my previous comment.)

Another method would be to change the "localhost" part. The standard
for IP addresses is that 127.x.y.z means localhost, regardless of what
x, y, and z are; so you could have one of them bind to 127.0.0.2 and
the other to 127.0.0.3, which you could then use in your browser the
same way (http://127.0.0.2:5000/ and http://127.0.0.3:5000/
respectively).

But if you can't change anything else, you'll have to make the two
processes cooperate in some way, or worst case, just make sure you
shut one down before you start the other up.

ChrisA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/29/22 23:22, Chris Angelico wrote:

On Tue, 30 Aug 2022 at 12:59, gene heskett <gheskett@shentel.net> wrote:

But that might create another problem. how to differentiate the servers,
both of which
will want to use localhost:5000 to serve up their web pages we run
things with.

Suggested solutions?

This is nothing to do with venvs, so I'm forking the thread.

By far the easiest way to differentiate them is to NOT have them both
on localhost:5000. Depending on how you invoke the servers, you should
be able to find a way to configure one (or both) of them to a
different port; common methods include a "--port" argument, setting
the PORT environment variable, and poking in the code to find the
number 5000 and changing it to some other value.

(Less common methods include poking in ctypes to find the number 5000
and changing it to some other value. Mentioned only because I realise
the alternative interpretation of my previous comment.)

Another method would be to change the "localhost" part. The standard
for IP addresses is that 127.x.y.z means localhost, regardless of what
x, y, and z are; so you could have one of them bind to 127.0.0.2 and
the other to 127.0.0.3, which you could then use in your browser the
same way (http://127.0.0.2:5000/ and http://127.0.0.3:5000/
respectively).

But if you can't change anything else, you'll have to make the two
processes cooperate in some way, or worst case, just make sure you
shut one down before you start the other up.

ChrisA

That is a limitation I'd druther not have to deal with Chris. I want two separate octoprint servers running with no interaction between them.

So I'm thinking of venv's named rock64prusa, and rock64ender5+, each with "port#" on my local net. So chromium could have two tabs open, one to localhost:5000 and one to localhost:5001, totally independent of each other.

I already have that in my /etc/hosts file. No dns resolving involved.

And from snooping just now, the port # is set it /etc/default/octoprint,
so copy
/etc/default/octoprint to octoprint-prusa, and to octoprint-ender5+, do
the same in
/etc/init.d, and change the port # & venv name  in the -ender5+ version.
Then
reconfigure the ender5+ version to drive that printer.

With the venv isolation, it should work, with a browser tab at
localhost:5000 and
another tab at localhost:5001, each pointing at its own directory tree
in /home/gene.

The separation is also because of the way linux finds usb facilities, the
prusa is always /dev/ttyACM0 and the ender5+ is almost always /dev/ttyUSB0.
in this case I've a 4 port usb hub with port disabling switches plugged
into the rock64.

One of the things I want to try is plugging in a startech usb3 to sata
adapter
with a small SSD plugged into it, and move the /tmp directory off that poor u-sd card to prolong its life.

And each with its own input buffer that cura can see from here. The new
cura 5.1
has its own set of problems, not being able to see octoprints defaulted
input buffer
hidden behind a dotted directory being a starter, toss in that it has no
way to look at
.. and that requires a user session of mc just to move the gcode
produced to be printed
from a local dir here to the input buffer of that instance of octoprint.

Back at this come daylight.  Thank you Chris.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 30 Aug 2022 at 19:51, gene heskett <gheskett@shentel.net> wrote:

So I'm thinking of venv's named rock64prusa, and rock64ender5+, each with "port#" on my local net. So chromium could have two tabs open, one to localhost:5000 and one to localhost:5001, totally independent of each other.

As I said, that has absolutely nothing to do with venvs, so you'd have
to figure out how to change their port numbers independently.

(Although you could probably add an env var to the venv's activation
script, if that would help.)

ChrisA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/30/22 06:52, Chris Angelico wrote:

On Tue, 30 Aug 2022 at 19:51, gene heskett <gheskett@shentel.net> wrote:

So I'm thinking of venv's named rock64prusa, and rock64ender5+, each with
"port#" on my local net. So chromium could have two tabs open, one to
localhost:5000 and one to localhost:5001, totally independent of each other. >>

As I said, that has absolutely nothing to do with venvs, so you'd have
to figure out how to change their port numbers independently.

(Although you could probably add an env var to the venv's activation
script, if that would help.)

ChrisA

The short script as /etc/default/octoprint has that PORT item. I see no
reason it
couldn't be renamed and edited to affect the desired separation.
(venv) gene@rock64:~/printrun/Printrun/venv$ cat /etc/default/octoprint ==============
# Configuration for /etc/init.d/octoprint

# The init.d script will only run if this variable non-empty. OCTOPRINT_USER=gene

# base directory to use, change this for cura in both copies so cura can
see it on the /sshnet
# make it unique and get rid of the dot.
BASEDIR=/home/gene/.octoprint

# configuration file to use, relocate this for uniqueness CONFIGFILE=/home/gene/.octoprint/config.yaml

# On what port to run daemon, default is 5000, anything not it use for
2nd ender5+ version
PORT=5000

# Path to the OctoPrint executable, you need to set this to match your installation!
# change the venv to a unique name DAEMON=/home/gene/OctoPrint/venv/bin/octoprint

# What arguments to pass to octoprint, usually no need to touch this DAEMON_ARGS="--port=$PORT"

# Umask of files octoprint generates, Change this to 000 if running
octoprint as its own, separate user
UMASK=022

# Process priority, 0 here will result in a priority 20 process.
# -2 ensures Octoprint has a slight priority over user processes.
NICELEVEL=-2

# Should we run at startup?
START=yes
====EOF====================

Edit two copies of this in defaults with individual names,

Edit 2 copies of /etc/init.d/octoprint with unique names

make two uniquely named venv's.

The two should never meet nor interfere with each other. So far, I've got
it running in a venv named prusa-mk3s. Now checking to see if it see's a
gcode file uploaded directly from cura here on this machine.

Short answer is no, octoprint cannot see an uploads directory in the
prusa-mk3s directory.
In fact, it cannot see, or even create a new uploads directory. But I
made one with mc, put
a gcode file there, not seen, got po'd and gave it 755 perms, bingo, it
needed exec perms,
and cura wasn't setting them. Chalk up another bitch at cura. Or at
octoprint, gcode is a text file
fur crying in the beer.  The rwXrwXrwX should not affect it IMO.

I need another batch of cable clips to neaten up the ender5+, so let me
see if it can do that.
Now that I have the rules in hand, maybe I can make a second copy work
at the same time.

IF I can figure out how to make it use a unique name for its PID identifier
.
Might have to change a character in the launchers name w/o changing the
script. Or better yet,
rename the executable?

IDK. And hour lateer, cable clips went nice and clean, so the first
instance is working fine.

And there isn't a PID for octoprint anyplace in /var unless its under
the snakes umbrella.

Progress, discovering bugs and work-arounds in octoprint. Now I'm
waiting on the mail for parts. Among other things a bigger PSU for the
rock64. See if that reduces the video glitches from usb activity.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)