If your server uses a self-signed certificate then yes you need the server.crt on the target and specified in mender.conf.
You follow the Yocto project section if that is the system you are using and the Debian section of you are using Debian or one if it’s variants.
Generally, editing and configuring Mender in a running system is certainly possible when you are adding lots of devices to your fleet but it’s more scalable and reproducible if you do it offline using your build system integration or the mender-convert utility (for binary distros).
Understood @drewmoseley Drew, Very clear.
In my case, it is lot of devices, and also have a Jetson Xavier and I see there isn’t a debian image or example in Mender Hub, thats why I specifically asked about editing and configuring.
Do you think in a long run, if I want to do system update or use more update modules, this method of editing and configuring will fail?
I’ll definitely explore on the Debian, but just want to get your opinion on this also.
I can’t comment on the Jetson specifically as I have never used that platform but you probably want to stick with the OS they provide as your base system unless you want to get into the business of maintaining your own.
I don’t see any reason the method of configuring Mender in a live running system will fail in the long run but it will become more work to maintain as each device will need to be done individually. If you work the configuration back into your build setup then it reduces that.
Sorry for the delayed response. Good to hear that the system is resilient.
I got the Jetson device also got connected to Mender through the Mender-client_arm64 image. l’ll explore yocto and debian images, But I just wanted to know the method of configuring is reliable or not. Now got your reply. Lets see, I’ll get back with updates.
Is there expiry for the server.crt ? If I need to upgrade the Mender server, will it cause prbs to the already connected Mender clients?
(Yes, Like you said, The server URL wont be changed, because that is how client connect to server)
I’m not sure about expiry on the crt but, yes if you change the cert used by the server, and you are not using a CA-signed cert, you will need to arrange to update the server.crt on the clients before you make the switch.
Drew
I understand so there is no server expiry unless I change the server.crt for my server. The current server shows “certificate Invalid”, So I guess I’ll change my server certificate to CA signed or something right? But then If i change my server certificate, Do I need to re-run the steps for production server again right, to generate new server.crt?
Is it possible to redeploy the already deployed release to my device, Because its in the testing phase, so everytime Im generating new release and uploading it. Its extremely important for my use case, because I’ll be using the post deployment API in my Mender-client, and its might need to redeploy the same release.
Also, guide me to how to update the Mender client if new version is released from your end, Because for sure these devices are gona be remote, so how to update these client version with all the parameters.
If I upgrade my production server to newer version, Will the server.crt be same and all mender clients still be connected ?
I understand so there is no server expiry unless I change the server.crt for my server. The current server shows “certificate Invalid”, So I guess I’ll change my server certificate to CA signed or something right? But then If i change my server certificate, Do I need to re-run the steps for production server again right, to generate new server.crt?
If you get a new server cert outside of the production server setup (ie by purchasing it from an agency) then you need to skip the steps in our docs that create the server and simply use the one provided by the agency.
Is it possible to redeploy the already deployed release to my device, Because its in the testing phase, so everytime Im generating new release and uploading it. Its extremely important for my use case, because I’ll be using the post deployment API in my Mender-client, and its might need to redeploy the same release.
No. The server will detect that the artifact name has not changed and refuse to re-send it. As long as the artifact name is changed then you should be ok.
Also, guide me to how to update the Mender client if new version is released from your end, Because for sure these devices are gona be remote, so how to update these client version with all the parameters.
The client is just part of the root filesystem so it depends on how you generated the image in the first place.
If you use Yocto then it is part of your Yocto build. When the updated client versions are available in your checked out Yocto layers, then simply rebuilding with the new commits will have the new version.
If you are using mender-convert then you will need to re-run that tool to make sure the newer client is included.
If any mender.conf file changes are needed they will be handled similarly.
If I upgrade my production server to newer version, Will the server.crt be same and all mender clients still be connected ?
As long as you don’t change the certificate file in your server setup directory.
I appreciate you taking time to respond.
I’m clear with pointers 1,2 and 4.
Just in pointer 3.I’m still not using yocto or Mender-convert, Im just directly changing the mender.conf using the parameter passing as we discussed earlier, In this case, how to update Mender client if newer version comes.
Also, in pointer 4, I’ll be using my self signed server.crt, but then will the site be safe even thou the cert can’t be verified as trusted?
You will need some mechanism to update mender.conf n the case that changes are needed. That can be using a file-based (Single File) or script-based update (Script) or some other out-of-band mechanism.
I cannot comment on the safety of the site. If the cert cannot be verified then you are vulnerable to man-in-the-middle attacks.
Sure @drewmoseley I’ll definitely explore on these two concerns and get back.
So, basically, When I want to upgrade the Mender client, I need to run through those set of parameters with the latest Mender client using single file or Script, thats what you are saying right. Sure will see that.
I have been testing the deployment, In the GUi i can see my latest artifact_name is changed to my recent release, but in the device its still None, In the /etc/mender/artifact_info, its “None”, Does it take time to change in device ? If its still None, how its updated in the GUI.
Also, very important, From Mender, Im deploying a python script which has a command “sudo chmod 777 -R file”, but this isn’t getting executing on the device, Is mender prohibited from giving chmod 777 to remote device files. Im using directory module.
The /etc/mender/artifact_info file is deprecated, and is not used after the first install. This file will probably be removed in a future Mender version. Use mender show-artifact to see which Artifact is installed.
I think the directory module is supposed to keep file permissions. Do you mean that the script does not get the right permissions, or that the sudo chmod 777 -R file inside the script does not work?
For my usecase, Im executing my mender deployment by checking the condition if “artifact_info = None” , if its gona be deprecated, You are suggesting that I use the condition based on Mender artifact result? Lets see how I can do that…
Yes, The python script which I’m deploying through directory module and then executing through “Script” module, Everything is working as per what My python script does except it is failing to give chmod -R 777 permission to other files (which Im executing in my script code) … Just and FYI: this python script which is executing is running as a systemd service.
Code:
os.system(“touch edge_automation.service”)
template_new = “”"[Unit]
Description=systemd service to run edge_automation script
[Service]
Type=simple
User=jetson01
ExecStart=/usr/bin/python3 /home/onboarding/automation.py
[Install]
WantedBy=multi-user.target"""
Here automation.py is my script which has all the “chmod -R 777 file perm” which isnt getting executed.
Hi @nishad1092 we don’t support modifying the artifact_name on the target. That is essentially the version of software that is installed. If you need to reset it to an older version, you should create a new deployment with the old artifact.
Drew
Ohk… Not the older artifact name actually. The very beginning of the device, artifact_name is Noneown, So just wanted to knw how to reset to that. I guess only way will be by reinstalling the Mender-Client.
hi @kacf
had this user management problem been fixed?
i used the latest mender 2.4.0 today which gives the mentioned problem by @nishad1092
direct url to /ui/#/settings/user-management also does not seem to do it
This works for me in 2.4.0 (yes, I did use the Open Source version this time! ). I even tried to use 2.4.0b1 (which doesn’t work) and then upgrade to 2.4.0. Works still.
hi @kacf
no its a fresh mender from scratch, removed the containers & volumes that existed before
i tried again with 3 different browser, just to be sure, because maybe it could have been some cache errors, but allas, still no user management
you think this would be something from my end that is not set up right?
). I even tried to use 2.4.0b1 (which doesn’t work) and then upgrade to 2.4.0. Works still.