Salt 0.15.1

[Thomas S Hatch]

We are embarrassed to say, but 0.15.0 had a number of showstopper bugs that required a quick update to 0.15.1. The sources for 0.15.1 were posted yesterday and the package maintainers were informed so that they could get a head start on packaging. Packages for Arch Linux and Debian (via debian.saltstack.org) are up. Packages will hit Fedora and EPEL this afternoon and Ubuntu packages are being finished. Windows installers will be released this afternoon as well.

In light of the bugs found in 0.15.0 we are looking into changing our release cycle to better allow for such issues to be found and we are looking at spending more time developing tests. We have also hired a few more full time employees to assist in the efforts to better stabilize Salt. The details about new hires and new release processes will be made public shortly.

This release fixes a serious security issue found in the way that RSA keys were being generated. Over the past year the cryptography in Salt has been reviewed privately by several security teams and have reported any issues or holes back to us. Somehow this one has slipped through. As a result, we are recommending that existing Salt keys be regenerated once 0.15.1 has been deployed on the master and all minions. A ‘key_regen’ routine has been added to 0.15.1 to make this transition easier. The following sequence is a convenient way to regenerate all keys in an environment:

   salt-run manage.key_regen

You will be prompted to restart the master. Once completed, all keys in the environment will have been regenerated and you will need to accept the new keys using the following command:

   salt-key -A

This security issue was discovered on Tuesday and we’ve been working non-stop to fix the issue, have the code re-audited and prepare the release.

As usual the source can be downloaded from pypi:

https://pypi.python.org/packages/source/s/salt/salt-0.15.1.tar.gz

We are deeply grateful for the continued support of Salt from our community. Salt Stack would not be where it is without this support!

Thomas S. Hatch  |  Founder, CTO

5272 South College Drive, Suite 301 | Murray, UT 84123

tha...@saltstack.com | www.saltstack.com

[Niels Abspoel]

Suse packagrs are alsook ready since yesterday.

[Thomas S Hatch]

Thanks Niels! Sorry I did not mention them!

Thomas S. Hatch  |  Founder, CTO

5272 South College Drive, Suite 301 | Murray, UT 84123

tha...@saltstack.com | www.saltstack.com

On Thu, May 9, 2013 at 12:54 PM, Niels Abspoel <abo...@gmail.com> wrote:

Suse packagrs are alsook ready since yesterday.

--
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.
For more options, visit https://groups.google.com/groups/opt_out.

[Corey Quinn]

Ubuntu PPA is updated with 0.15.1.

-- Corey

[Les Mikesell]

On Thu, May 9, 2013 at 9:23 PM, Corey Quinn <co...@sequestered.net> wrote:
>
> Ubuntu PPA is updated with 0.15.1.

Hate to complain about free software but I'm still seeing 0.14.1 in
EPEL6 and 0.14.0 in EPEL5.

--
Les Mikesell
lesmi...@gmail.com

[Les Mikesell]

On Thu, May 9, 2013 at 9:23 PM, Corey Quinn <co...@sequestered.net> wrote:
>

> Ubuntu PPA is updated with 0.15.1.

[Thomas S Hatch]

EPEL packages hit epel testing first and sit there for a few weeks. Take a look at epel testing

Thomas S. Hatch  |  Founder, CTO

5272 South College Drive, Suite 301 | Murray, UT 84123

tha...@saltstack.com | www.saltstack.com

[Lonni J Friedman]

​Either that's not working, or I'm doing something wrong (RHEL6):
​# yum --enablerepo=epel-testing update salt*
Loaded plugins: product-id, security, subscription-manager
Setting up Update Process
No Packages marked for Update

On Fri, May 10, 2013 at 9:53 AM, Thomas S Hatch <that...@gmail.com> wrote:

EPEL packages hit epel testing first and sit there for a few weeks. Take a look at epel testing

[Joseph Hall]

It hasn't made it to epel-testing yet. Herlo will get it there soon, I'm sure.

> --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
"In order to create, you have to have the willingness, the desire to
be challenged, to be learning." -- Ferran Adria (speaking at Harvard,
2011)

[Andrew Niemantsverdriet]

Les,

You are right they are not there yet, I swear I saw them last night in testing. I will dig into this with herlo and figure out what is up.

You should be able to yum --enablerepo=epel-testing install salt to get updated packages.

--
 _
/-\ ndrew Niemantsverdriet
Linux System Administrator
Academic Computing
(406) 238-7360
Rocky Mountain College
1511 Poly Dr.
Billings MT, 59102

[Les Mikesell]

On Fri, May 10, 2013 at 12:07 PM, Andrew Niemantsverdriet
<and...@rocky.edu> wrote:
>
> Les,
>
> You are right they are not there yet, I swear I saw them last night in testing. I will dig into this with herlo and figure out what is up.
>
> You should be able to yum --enablerepo=epel-testing install salt to get updated packages.
>

Yes, I meant to say epel-testing - and I didn't mean to post it twice
if 2 copies went out...

I think it should show here:
http://dl.fedoraproject.org/pub/epel/testing/6/SRPMS/repoview/letter_s.group.html
besides yum finding it.

--
Les Mikesell
lesmi...@gmail.com

[Andrew Niemantsverdriet]

Les,

It is on its way right now, should show up within the hour.

[Les Mikesell]

On Fri, May 10, 2013 at 12:17 PM, Andrew Niemantsverdriet
<and...@rocky.edu> wrote:
>
> It is on its way right now, should show up within the hour.
>

Thanks! I wonder if I'm the only one on the list using RHEL or
CentOS, or if I'm just the only one crass enough to complain.

--
Les Mikesell
lesmi...@gmail.com

[Mike Chesnut]

I'm using CentOS, Les!  (I build my own RPMs, though.)

--
   Les Mikesell
     lesmi...@gmail.com

[Corey Quinn]

I've got a blended personal environment that I can't update until EPEL hits because the master is a CentOS machine.

However, I can't complain because:

1. I'm doing the Ubuntu packages and I know what a pain it is, and
2. I see Herlo at least once a year. He looks like he bench presses Buicks for fun. If he hits me, there's not likely to be a whole lot left!

-- Corey

[Les Mikesell]

On Fri, May 10, 2013 at 1:05 PM, Corey Quinn <co...@sequestered.net> wrote:
> I've got a blended personal environment that I can't update until EPEL hits because the master is a CentOS machine.

Maybe I've lost touch, but I'd expect most organizations big enough to
need salt to also need the stability of RHEL or CentOS so I'd think it
would make sense to focus development there at least for the master.
I have enough trouble with the 5+ year upgrade cycle. I also think
it would be great to have separate stable/unstable/nightly packaged
releases like some other projects do, so you could run unstable for
testing where you have the facilities and the stable version wouldn't
be updated until there had been some time for bugs to be noticed and
fixed. I think that might encourage a little more widespread
testing.

--
Les Mikesell
lesmi...@gmail.com

[Colton Myers]

We're working towards hosting our own repos with unstable packages and so forth, which will solve many of those problems.

--

Colton Myers

--
   Les Mikesell
    lesmi...@gmail.com

[Corey Quinn]

On May 10, 2013, at 11:31 AM, Les Mikesell <lesmi...@gmail.com> wrote:

> On Fri, May 10, 2013 at 1:05 PM, Corey Quinn <co...@sequestered.net> wrote:
>> I've got a blended personal environment that I can't update until EPEL hits because the master is a CentOS machine.
>
> Maybe I've lost touch, but I'd expect most organizations big enough to
> need salt to also need the stability of RHEL or CentOS so I'd think it
> would make sense to focus development there at least for the master.
> I have enough trouble with the 5+ year upgrade cycle. I also think
> it would be great to have separate stable/unstable/nightly packaged
> releases like some other projects do, so you could run unstable

It's reading my own thoughts that I sent to the packagers being read back to me!

My term for unstable builds: salt-inthewound.

But yes, I'm totally on board with this. As the number of installed bases grow, a long-term supported version becomes more and more critical. "You're two weeks out of date, upgrade!" is terrifying when applied to production critical environments!

-- Corey

> for
> testing where you have the facilities and the stable version wouldn't
> be updated until there had been some time for bugs to be noticed and
> fixed. I think that might encourage a little more widespread
> testing.
>
> --
> Les Mikesell
> lesmi...@gmail.com
>

[Colton Myers]

Well, technically long-term support is what Salt Stack Enterprise is for.  ;-)

That said, we are working towards release candidates and similar.

--

Colton Myers

[Corey Quinn]

On May 10, 2013, at 11:46 AM, Colton Myers <colton...@gmail.com> wrote:

Well, technically long-term support is what Salt Stack Enterprise is for.  ;-)

That said, we are working towards release candidates and similar.

While a wonderful theory, "not destroying your production environment" as a premium feature is somewhat worrying. ;-)

-- Corey

[Les Mikesell]

On Fri, May 10, 2013 at 1:39 PM, Corey Quinn <co...@sequestered.net> wrote:
>
> My term for unstable builds: salt-inthewound.
>
> But yes, I'm totally on board with this. As the number of installed bases grow, a long-term supported version becomes more and more critical. "You're two weeks out of date, upgrade!" is terrifying when applied to production critical environments!
>

Exactly, and the concept that you need some library or system call
that doesn't exist on the OS that has been running perfectly for years
is also fairly incomprehensible to me. There haven't been that many
great advances in computer science since unix was invented (or at
least tcp). But the other thing that is slightly disconcerting about
salt is that it doesn't seem that great about managing its own updates
(sometimes needs a separate restart, sometimes not, picky about
version matches, etc.). I think that needs to be rock solid before
trusting it to manage anything else.

--
Les Mikesell
lesmi...@gmail.com

[Corey Quinn]

Not sure I agree here. Self management is arguably the hardest problem to solve, akin to picking yourself up off the ground.

But yes, we could use some stability around this. It's also worth mentioning that Ubuntu/Debian in its infinite wisdom decides that if you're installing a package that provides a daemon, that daemon should immediately be (re)started, with a default configuration. CentOS/RHEL takes the opposite approach of "we'll let you explicitly manage that." Not saying this excuses the behavior, but it's hard to determine which is the principle of least surprise…

-- Corey

[Les Mikesell]

On Fri, May 10, 2013 at 2:51 PM, Corey Quinn <co...@sequestered.net> wrote:
>
>> But the other thing that is slightly disconcerting about
>> salt is that it doesn't seem that great about managing its own updates
>> (sometimes needs a separate restart, sometimes not, picky about
>> version matches, etc.). I think that needs to be rock solid before
>> trusting it to manage anything else.
>
> Not sure I agree here. Self management is arguably the hardest problem to solve, akin to picking yourself up off the ground.

I didn't say it was easy, I said it needed to do it before it makes
sense to use. That is, if I am able to deal with this hard problem
without salt, remind me of why I need it in the first place...

> But yes, we could use some stability around this. It's also worth mentioning that Ubuntu/Debian in its infinite wisdom decides that if you're installing a package that provides a daemon, that daemon should immediately be (re)started, with a default configuration. CentOS/RHEL takes the opposite approach of "we'll let you explicitly manage that." Not saying this excuses the behavior, but it's hard to determine which is the principle of least surprise…

And who is supposed to manage the requirement of the minion version
never being newer than the master?

--
Les Mikesell
lesmi...@gmail.com

[Mrten]

On 10/5/2013 21:51 , Corey Quinn wrote:

> It's also worth mentioning that Ubuntu/Debian in its infinite wisdom
> decides that if you're installing a package that provides a daemon,
> that daemon should immediately be (re)started, with a default
> configuration. CentOS/RHEL takes the opposite approach of "we'll let
> you explicitly manage that." Not saying this excuses the behavior,

> but it's hard to determine which is the principle of least surprise�

Are you sure that a service should be restarted? Can't seem to find that
here:

http://www.debian.org/doc/debian-policy/ch-opersys.html

I've seen new packages need edits to /etc/default/[file] before starting
at all, spamassassin comes to mind, hence the question.

This link does echo your sentiments:

http://ask.debian.net/questions/how-to-prevent-daemons-from-starting-at-installation-time

and mentions a knob (policy-rc.d).

That being said, I like that my daemons are restarted when I upgrade a
package; I would worry about missing files otherwise. I don't upgrade
packages unless I want the service from it restarted, but perhaps this
is something you get used to depending on which distro you're using?

Thoughts?

M.

[Lex H]

I got in a bit of a bind after running "salt-run manage.key_regen".

Turns out I was left with an out of date "master_finger" in each of my minion's configs.

Should this be handled in key_regen? At a minimum, it's probably worthwhile documenting this step may be necessary (updating master_finger) as part of the 0.15.1 release note docs.

BTW I didn't originally set "master_finger", but it appears salt-cloud sets this when it spins up machines for you.

Thanks,

Lexual.

--

[Thomas S Hatch]

Ouch, thanks Lex, I will get that in the documentation and look into adding it to key_regen

Thomas S. Hatch  |  Founder, CTO

5272 South College Drive, Suite 301 | Murray, UT 84123

tha...@saltstack.com | www.saltstack.com

[Wenhao Xu]

I built RPM for 0.15.1 on CentOS 6.4 today. There is still one test failed. So I have to disable the test check when building the RPM.

This fix(367927b) seems not included in v0.15.1.

Regards,

Wenhao

[Clint Savage]

Wenhao,

I noticed the same error. @thatch45 asked me to disable the tests for now, but I expect 0.15.2 will re-enable them. It's something about the ordering of the tests (which means the test probably need to be rewritten).

If you use the EPEL repository, you don't have to build your own RPM. 0.15.1 is in the epel-testing repo. Just visit http://fedoraproject.org/wiki/EPEL and set it up. You can also use the spec file provided in the salt repo @ https://github.com/saltstack/salt/blob/develop/pkg/rpm/salt.spec

Cheers,

herlo

--