Apply a state only after a system reboot

[Rainer Krienke]

Hello,

I would like to apply a state (upgrading packages) only after a system
boot when the salt-minion comes up fot the first time, and not again
after each salt interval say eg 30 min like for regular states.

A simple solution would be to write Jina code that excludes a state if
the system is up more than 30min. I did this when I was still using
puppet and it worked well. In salt I do not exactly know what the best
solution is, and how to formulate it syntactically.

status.uptime delivers the clients uptime in several formats and if
Jinja and salt would allow to write something like

{% if salt[status.uptime.seconds] < 1800 then %}
doupgrade:
....
{% endif %}

everything would be ok for me. Does anyone know if this is possible?

Another solution would be to introduce a new grain that contains the
current uptime, that I would have to write in phython and then check
for the grains value if this value is less than eg 1800sec using Jinja
similar to the example from above.

Thanks for your help
Rainer

[Rémy Dernat]

Hi,

Considering you don't restart the minion manually, you can do much simpler, simply by checking if the minion is trying to reconnect, and creating a reactor or an orchestrator :

  - https://docs.saltstack.com/en/latest/topics/event/master_events.html

  - https://docs.saltstack.com/en/latest/topics/reactor/

Then apply your upgrades (BTW : I am not a huge fan of automatically blind upgrades; I did this in the past, and sometimes a manual control can save your time from many circumstances).

Kind regards,

Rémy

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/salt-users/cf090c0e-7eac-ae4c-1174-b415a7c78d08%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.

[Rainer Krienke]

Hi Rémy,

thank you very much for your answer. Well actually I would prefer to
keep all code that is responsible for package upgrades in one state
file, so that I do not have to remember that some of the code is in a
state file and another part is beacon/reactor based.

I have already a beacon/reactor config that checks filesystem usage
(df), but this one is only realized by a beacon/reactor, so its in "one"
place only.

So if anyone has another answer how my problem could be solved inside a
state file I would really be interested to see how?

As far as automatic upgrades are concerned I think depending on the
number of machines you do not have a real choice. The systems (multiboot
client systems) I want to upgrade upon boot have a total count of about
100 and are running windows most of the time. Only if the system is
rebooted to linux salt will take care of the linux system. So running
linux upgrades manually is verytime intensive.

Thanks a lot
Rainer

Am 26.10.18 um 10:17 schrieb Rémy Dernat:

> Hi,
>
> Considering you don't restart the minion manually, you can do much
> simpler, simply by checking if the minion is trying to reconnect, and
> creating a reactor or an orchestrator :
>   - https://docs.saltstack.com/en/latest/topics/event/master_events.html
>   - https://docs.saltstack.com/en/latest/topics/reactor/
>
> Then apply your upgrades (BTW : I am not a huge fan of automatically
> blind upgrades; I did this in the past, and sometimes a manual control
> can save your time from many circumstances).
>
> Kind regards,
> Rémy
>
> Le ven. 26 oct. 2018 à 10:00, 'Rainer Krienke' via Salt-users

> <salt-...@googlegroups.com <mailto:salt-...@googlegroups.com>> a écrit :

> <mailto:salt-users%2Bunsu...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/salt-users/cf090c0e-7eac-ae4c-1174-b415a7c78d08%40googlemail.com.
> For more options, visit https://groups.google.com/d/optout.
>

> --
> You received this message because you are subscribed to the Google
> Groups "Salt-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to salt-users+...@googlegroups.com

> <mailto:salt-users+...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/salt-users/CAA6Bz%3DdJYR4g_25Q_Q-V0rQZDetEkM4avFYhWzZNVqVS0F%3D_Tg%40mail.gmail.com
> <https://groups.google.com/d/msgid/salt-users/CAA6Bz%3DdJYR4g_25Q_Q-V0rQZDetEkM4avFYhWzZNVqVS0F%3D_Tg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Steven Oliver]

When configuring the minion, you can give it a list of start-up states:

https://docs.saltstack.com/en/latest/ref/configuration/minion.html#startup-states

Steven N. Oliver

To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/salt-users/8352b682-765b-ebf5-e1e2-78bc4cf0ad8d%40googlemail.com.

[Schotten Sozial]

You could just write an init script / systemd timer / etc. which fires up "salt-call state.apply yourcustomupdatestate" at system boot, optionally with a delay timer... we use "at" for this. That's how we are doing thinngs just for the first minion startup. The init script itself could be managed by salt.

[Rainer Krienke]

Hello,

thank you all very much for your answers. Peronally I found the solution
of Schotten Sozial very intuitive. Because I already had a script that
does the whole upgrade task, I now implemented a variant of the proposal
below:

I use salt to manage a systemd-service file which starts my update
script when the system is coming up. This is simple and seems to work
without problems.

Thanks a lot to all
Rainer

Am 27.10.18 um 13:24 schrieb Schotten Sozial:

> --
> You received this message because you are subscribed to the Google
> Groups "Salt-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to salt-users+...@googlegroups.com
> <mailto:salt-users+...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/salt-users/1f0b1b05-8da9-4f3b-9d1a-bca834a0d931%40googlegroups.com
> <https://groups.google.com/d/msgid/salt-users/1f0b1b05-8da9-4f3b-9d1a-bca834a0d931%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Rainer Krienke]

Hello,

thank you all very much for your answers. Peronally I found the solution
of Schotten Sozial very intuitive. Because I already had a script that
does the whole upgrade task, I now implemented a variant of the proposal
below:

I use salt to manage a systemd-service file which starts my update
script when the system is coming up. This is simple and seems to work
without problems.

Thanks a lot to all
Rainer

Am 27.10.18 um 13:24 schrieb Schotten Sozial:

[Rainer Krienke]

Hello,

thank you all very much for your answers. Peronally I found the solution
of Schotten Sozial very intuitive. Because I already had a script that
does the whole upgrade task, I now implemented a variant of the proposal
below:

I use salt to manage a systemd-service file which starts my update
script when the system is coming up. This is simple and seems to work
without problems.

Thanks a lot to all
Rainer