Closed philipstarkey closed 7 years ago
Original comment by Philip Starkey (Bitbucket: pstarkey, GitHub: pstarkey).
So the labconfig is supposed to refer to the PC name, which under windows at least, in independent of hostname assigned by a network. I believe this is also true on linux?
We could consider having it load the config specified in "dynamic hostname.ini" if it can't find a matching one for the hostname ("dynamic hostname" being an invalid hostname since it contains a space so will never conflict with the name of another .ini file)
Is this just an issue on OSX and is there a better solution/workaround?
Original comment by Jan Werkmann (Bitbucket: PhyNerd, GitHub: PhyNerd).
I tested this behavior on windows and the hostnames stayed the same. So I guess it's a macOS and maybe other flavours of unix thing. Under macOS the hostname is more of a DNS name. In the lab I have "JWrkPC.local.ini" at home its "JWrkPC.fritz.box.ini" and in the university eduroam I get "sXXXX.dyn.hrz.tu-darmstadt.de.ini" where XXXX is a random 4 digit number. So there is no easy way of extracting the computername like splitting before the dot. I'll try to find something equivalent to the computername for macOS that is better than a MAC or a UUID.
Original comment by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).
I believe it's macos only, from what I've read.
A fixed hostname can be set in macos with sudo scutil --set HostName <putinyourhostname_or_fqdn_here>
according to this stackexchange discussion.
This blog post, though a bit out of date, mentions that macos has several possible options to choose from when setting the hostname. It goes for the dynamic options first, but the other options exist.
And this one talks about how to access the other options.
Perhaps we can have python call out to scutil --get ComputerName
on macos instead for example, and use that. I am unclear on whether ComputerName is a hostname in any sense - whether it matches the requirements of being a hostname format-wise, and whether pinging it pings localhost or not. If it is both of these things then we should use it, and if it's none then, well, I think we should still probably use it.
I like hostnames or other "names" better than MAC addresses because they're human recognisable (well, the ones you set up yourself are), and these are supposed to be human-editable configs that you keep in version control or something with potentially all the computers' files in the same version control repository. So having a bunch of MAC addresses is pretty unfriendly. Plus, I've changed wifi cards at least once on most computers I've owned (the ones they come with often work poorly on linux), whereas I've never changed hostname :p
Original comment by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).
it looks like ComputerName probably is a hostname - possibly isn't pingable without appending ".local" to it, but I think it ought to be good enough for us.
Perhaps @PhyNerd can confirm, and if it looks good then we can make the labconfig module have a if sys.platform == 'darwin'
and then do a call out to scutil --get ComputerName
.
We would then have to get rid of the places where the labconfig file is hard coded to be socket.gethostname()
instead of getting it from the labconfig module:
#!python
labscript_suite $ grep -r 'hostname()' --include '*.py' *
blacs/__main__.py: config_path = os.path.join(config_prefix,'%s.ini'%socket.gethostname())
blacs/__main__.py: settings_path = os.path.join(config_prefix,'%s_BLACS.h5'%socket.gethostname())
blacs/standalone_device.py: config_path = r'C:\labconfig\\'+socket.gethostname()+r'.ini'
blacs/standalone_device.py: settings_path = r'C:\labconfig\\'+socket.gethostname()+r'_BLACS.h5'
labscript_utils/labconfig.py:default_config_path = os.path.join(config_prefix,'%s.ini'%socket.gethostname())
lyse/__main__.py: config_path = os.path.join(config_prefix, '%s.ini' % socket.gethostname())
runmanager/__main__.py: config_path = os.path.join(config_prefix, '%s.ini' % socket.gethostname())
runviewer/__main__.py: config_path = os.path.join(config_prefix, '%s.ini' % socket.gethostname())
Original comment by Jan Werkmann (Bitbucket: PhyNerd, GitHub: PhyNerd).
The thing we want is "scutil --get LocalHostName" as this returns my networkname "JWrkPC". The proposed "scutil --get ComputerName" returns the full computer name "Jans MacBook Pro". Adding this would definitely fix things for me (seems I'm stubeling over lots of these mac specific bugs) but it's not that big of a priority.
Shouldn't we be using the labconfig module everywhere anyway?
Original comment by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).
Ah, great! Well it's looking like LocalHostName is the solution then on macos.
Yes, we should! The programs hard-coding paths is historical - the labconfig module used to not know anything about where the files actually were, and it slowly grew a 'prefix' at least, and then the full filename, but there's still some old code around that is using just the prefix. They shouldn't even be using the full filepath - they should just be instantiating a LabConfig() object with its default arguments.
Original comment by Jan Werkmann (Bitbucket: PhyNerd, GitHub: PhyNerd).
I'll create a pullrequest for labscript_utils and then look at lyse, runmanager, runviewer and BLACS later
Update: everything but BLACS has a pullrequest now but BLACS is pretty much the same as all others just that it needs to import hostname from labconfig will do this later
Original report (archived issue) by Jan Werkmann (Bitbucket: PhyNerd, GitHub: PhyNerd).
Having labsconfig named after hostname can cause problems under mobile systems, as they can have changing hostnames in different network environments. Possible solutions:
New identifier that is better than hostname
a file that saves what config file to use