Hi,
I’m trying to change hostname on resinos (not resinio) - I can change it with:
echo resindog > /etc/hostname && hostname -F /etc/hostname
but it doesn’t persist on reboot and I can never ping resindog.local
another technique yields this
root@resin:~# hostnamectl set-hostname resindog Could not set property: Failed to set static hostname: Read-only file system
Any ideas?
Hey, here is a bit in the docs to get you started: https://docs.resin.io/runtime/runtime/#change-the-device-hostname In a nutshell you have to communicate with the host OS over dbus.
Actually, this is what I tried first, however, I’m running under a user other than root, and I therefore get a security error - I’ll try to run it again & report back, but any suggestions on this?
I’m running a custom user both for security, and so I can switch their home folder to /data so it is persisted between container sessions.
Good point on using custom user, I’m guessing it should be possible to enable access to the dbus sockets from non-root users. I see the result is Failed to open connection to "system" message bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
This seems to be the same popping up for other dbus-send calls as well, checking it with the team!
Yes, that’s exactly the message I got.
It seems to me there’s a lot of issues with read only filesystem where it needs to be writeable - also cant change IP address back to dhcp from fixed IP address (see subsequent post).
The read-only file system is really your friend, it just takes some time to get used to that you don’t manipulate things in the hostOS directly but through an interface. Here’s the issue is likely the security setup within the container, and not anything with the host, and should be solvable with updates in the base image configuration, just checking what is the exact cause.
What sort of thing are you building that requires these network manipulation? Just so that we can understand your case and think about it appropriately.
Hi there - I get this, but as discussed cant use dbus from a non-root user, and it’s not got great docs, it’d be way nicer to use well-documented linux admin commands.
Use case is creating multiple devices, not connected to internet (ie. not resin-io) and needing to switch all of their network config, ie. hostnames, ip address/dhcp, wifi etc, via a UI hosted within a container on the device. Currently doing a fair amount of this via ssh to device, ie. calls like
ssh root@172.17.0.1 -p22222 '/sbin/ifconfig'
if/when this approach floats, I would then look to lock down the host to need ssh keys, and give this one special container the ssh key.
Thoughts? Happy to consolidate discussion here or on the other thread, or take offline & post results here.
Just curious if sudo would work for your purposes with dbus? You can set up /etc/sudoers to allow passwordless access to dbus for your user account and limit it to dbus only:
customuser ALL = (root) NOPASSWD: /usr/bin/dbus-send
EDIT: Just to be clear, ‘customuser’ above would be the user account you want to give sudo access to. So if the username is ‘fred’, you’d replace ‘customuser’ with ‘fred’.
Finally, just so I understand your use case, are you doing an initial provisioning of these devices through resin.io while they are connected to the internet and then moving them to a private network?
Thanks - that could be useful, I’ll give it a go when I get back to it.
We’ve actually decided recently that some deployments might have access via resinIO, however some in future definitely might not - ie. setting up resinos in a disconnected, isolated environment.
Hey, sorry I’ve dropped this, discussed the issue internally recently and here are some extra thoughts. The main thing is that most Linux setups require root access to change system settings like networking, so actually that root requirement is not really unreasonable from the point of view of consistent privilege levels. This would probably be an issue in general, as if someone gains access to within your container, they could control the device through the dbus if the current user have access to dbus. Thus probably the threat models need a bit more thinking.
Also, the current resinOS (I think you are on that) is a development release with no root password set anyways, so in this case you are not gaining much with any of this separate user setup.
Indeed, we’ve discussed this internally here too & decided on a hybrid sudo approach, hopefully with a single-responsibility container to do the job - again, I’ll get back to this after then next dev phase.