wetting my feet with CM software
-
@scottalanmiller said in wetting my feet with CM software:
@matteo-nunziati said in wetting my feet with CM software:
- The relevant thing here is: how can massively create this user from a plain VM not customized at installation time and deployed on N VMs (with N possibly really big)? Maybe a datacenter can customize an iso, but a small company like mine is best server by Ansible like solutions, especially in disaster recovery scenarios, where you have to think fast at a lot of things.
Why would you not have your VM customized? Size doesn't make any difference. Even if you are a one man shop with one server, you would customize your installation distro. We do this just for our lab alone, for example. And we do it on Vultr or Linode. Makes everything much easier and standardized, even if you are not using a tool like Ansible or Salt. In fact, the smaller you are, the more important that efficient processes be used. Big companies can afford to be more lax, and often are.
mmm... link please
(OK, after luch I will search for it anyway) -
@matteo-nunziati said in wetting my feet with CM software:
@scottalanmiller said in wetting my feet with CM software:
@matteo-nunziati said in wetting my feet with CM software:
- The first thing to consider as now is that Salt is less available than Ansible in distros’ packages. Moreover, being Ansible backed by Red Hat is possible that they will purge Salt as they done with Xen.
What do you mean purge? Xen is still supported by Red Hat and XenServer is still built on it.
I mean that new Rad Hat products have KVM per default and Xen, to my humble opinion, is a second class citizen - at least since Red Hat 7. Of course they support their previous releases, and of course XenServer is built on it, but it is based on the CentOS distro and is supported by the XenServer project (Linux Foundation?) not by direct Red Hat support.
True, but you really don't bring in Salt from Red Hat sources, at least we don't. We use Salt's own tools.
-
@matteo-nunziati said in wetting my feet with CM software:
@scottalanmiller said in wetting my feet with CM software:
@matteo-nunziati said in wetting my feet with CM software:
- Salt doesn’t work well with sudo. It requires that the user has NOPASSWD rights for sudo. This basically kills usage on any Ubuntu like distro. The solution is to manually add a special locked user with NOPASSWD rights in sudoers. In fact, giving the standard user NOPASSWD is close to security suicide.
This isn't a standard user, though, so that this is considered bad for standard users isn't applicable here. So that's not a negative.
It is negative in that I've to make adjustements to "plain" installed distros by hand, or at least other configuration tools. Then having a dedicated locked down user is perfectly OK.
That's considered a basic in any environment, though, whether you are using Ansible or Salt. Just getting your keys in place requires an adjustment to the base install, so Ansible doesn't work without a modified base either.
-
@matteo-nunziati said in wetting my feet with CM software:
@scottalanmiller said in wetting my feet with CM software:
@matteo-nunziati said in wetting my feet with CM software:
- Considering this, instrumentation is a bit more of a trouble in Salt: while Ansible can check with pure shell commands for its platform requirements (and install them), you have to force salt to install those items from a salt-ssh cmd line. It can’t create a state file for instrumentation in the likes of ansible “instrumentation” playbooks.
- This implies that rebuilding an infrastructure is not a one line away with Salt as it is with Ansible, first you need to instrument with salt-ssh, then run environments (cascade of playbooks in Ansible terms). As a side note ansible requires libselinux-python as additional dependency in CentOS 7, while Salt doesn’t.
What do you mean? You'd have Salt built into your base image. So none of this would apply in normal circumstances. Salt would already be installed along with all dependencies before you even start.
that's the point: if you run a standard ISO from canonical or redhat/centos, you have not it installed by any default install: you have to add it and/or preseed the installer (never done this, so I'd have to experiment with this).
Same with Ansible, there is no agent there by default, nor keys for accessing the OS. Neither "just works". Nothing does. And just doing installs from ISO is a lot of effort that isn't needed. That's way more time consuming and complex than doing one install, installing keys for Ansible or the agent for Salt, running updates for security then making an image. Making a new install is seconds after that, instead of a long time. It's worth it, even for a single additional install.
-
@matteo-nunziati said in wetting my feet with CM software:
To me it is better to run salt-ssh to instrument your target machines, rahter than preseed an image. This is massive do not requires you to poke with isos ad so...
This is where we differ. As someone who never uses the ISOs and always preseeds, I'm unclear what benefit there is from using the ISOs, ever (other than the very first time, obviously.) I want to avoid the ISOs as much as possible, I see them as purely a negative from all aspects. They are slow, risky (because we don't ensure standard security) and cumbersome. Even without CM tools we never used the ISOs. We pre-seeded keys, standard packages, latest updates, etc.
So what's the reason you choose ISOs? What benefit are you seeing from all that extra work?
-
@matteo-nunziati said in wetting my feet with CM software:
@scottalanmiller said in wetting my feet with CM software:
@matteo-nunziati said in wetting my feet with CM software:
- The relevant thing here is: how can massively create this user from a plain VM not customized at installation time and deployed on N VMs (with N possibly really big)? Maybe a datacenter can customize an iso, but a small company like mine is best server by Ansible like solutions, especially in disaster recovery scenarios, where you have to think fast at a lot of things.
Why would you not have your VM customized? Size doesn't make any difference. Even if you are a one man shop with one server, you would customize your installation distro. We do this just for our lab alone, for example. And we do it on Vultr or Linode. Makes everything much easier and standardized, even if you are not using a tool like Ansible or Salt. In fact, the smaller you are, the more important that efficient processes be used. Big companies can afford to be more lax, and often are.
mmm... link please
(OK, after luch I will search for it anyway)Just back from the grocery now. Link to what exactly? To how we do it on Vultr, for example?
-
@scottalanmiller said in wetting my feet with CM software:
Same with Ansible, there is no agent there by default, nor keys for accessing the OS. Neither "just works". Nothing does. And just doing installs from ISO is a lot of effort that isn't needed. That's way more time consuming and complex than doing one install, installing keys for Ansible or the agent for Salt, running updates for security then making an image. Making a new install is seconds after that, instead of a long time. It's worth it, even for a single additional install.
mmm... I got it! I prefer to clone plain vanilla rather than rebuild my images (I mean VM images) so that's where my considerations comes from. In this specific case it would mean to add a standard user locked down without password. Therefore it could be rather straight forward to have the user in place and "clone" it as you have not to add different users/passwords.
Still, from a more detailed POW: still do you think that having the agent into the image is better than use the ssh approach? I always end up considering that an ssh is always good as a fallback. I'm comparing here Salt master/minion vs Salt-ssh to make that clear.
-
@scottalanmiller link to direct commands in Salt.
-
@matteo-nunziati said in wetting my feet with CM software:
@scottalanmiller said in wetting my feet with CM software:
Same with Ansible, there is no agent there by default, nor keys for accessing the OS. Neither "just works". Nothing does. And just doing installs from ISO is a lot of effort that isn't needed. That's way more time consuming and complex than doing one install, installing keys for Ansible or the agent for Salt, running updates for security then making an image. Making a new install is seconds after that, instead of a long time. It's worth it, even for a single additional install.
mmm... I got it! I prefer to clone plain vanilla rather than rebuild my images (I mean VM images)
I figured that out... but why? Why leave out the standardization stuff that is where all the power is?
-
@matteo-nunziati said in wetting my feet with CM software:
Still, from a more detailed POW: still do you think that having the agent into the image is better than use the ssh approach? I always end up considering that an ssh is always good as a fallback. I'm comparing here Salt master/minion vs Salt-ssh to make that clear.
Yes, not having SSH at all I consider the biggest "slam dunk" for Salt. I see needing to SSH into a machine ever as a bit of a failure now. I don't want SSH to even run, let alone be needed.
-
@matteo-nunziati said in wetting my feet with CM software:
@scottalanmiller link to direct commands in Salt.
Still not clear, which commands are you looking for?
-
@scottalanmiller said in wetting my feet with CM software:
Still not clear, which commands are you looking for?
@scottalanmiller said in wetting my feet with CM software:
You left out instant commands.
Those commands and the link to them in the docs.
-
@scottalanmiller said in wetting my feet with CM software:
@matteo-nunziati said in wetting my feet with CM software:
Still, from a more detailed POW: still do you think that having the agent into the image is better than use the ssh approach? I always end up considering that an ssh is always good as a fallback. I'm comparing here Salt master/minion vs Salt-ssh to make that clear.
Yes, not having SSH at all I consider the biggest "slam dunk" for Salt. I see needing to SSH into a machine ever as a bit of a failure now. I don't want SSH to even run, let alone be needed.
wowa that's would be a good article on best practices and "why you need access (and which) to your machine".
My mind set is always:
1- be sure to have local access. (in VM this is the virtual console provided by the hypervisor)
2- be sure to have remote access.
3- implement any other mechanism of communication with the machine (like Salt in this case)but I never close any of the others later. Just keep them as fallback.
btw, remaining on the Ansible/Salt comparison I would like to have an opinion also from @stacksofplates , being he an avid ansible user.
-
@scottalanmiller said in wetting my feet with CM software:
@matteo-nunziati said in wetting my feet with CM software:
mmm... I got it! I prefer to clone plain vanilla rather than rebuild my images (I mean VM images)
I figured that out... but why? Why leave out the standardization stuff that is where all the power is?
Because my approach is: what is upstream is default, what is mine it is not. As I do not provide services to others, I do not need to be an upstream for someone else, therefore I always restart from scratch. And having a CM to do this for me is a real added value.
I mean that as setting up a cronjob in a reproducibile manner is important for a certain class of service (say a backup) It is also important to me to setup everything from scratch in a reproducible manner.ex.:
- I've changed my keys? just re-deploy them
- Salt/Ansible run with python3? just avoid to use the available image with python-minimal on it. just drop it from the playbook/state
-
@matteo-nunziati said in wetting my feet with CM software:
@scottalanmiller said in wetting my feet with CM software:
Still not clear, which commands are you looking for?
@scottalanmiller said in wetting my feet with CM software:
You left out instant commands.
Those commands and the link to them in the docs.
OH!
First example here, the cmd.run option...
https://mangolassi.it/topic/11821/executing-basic-commands-with-salt
-
@matteo-nunziati said in wetting my feet with CM software:
@scottalanmiller said in wetting my feet with CM software:
@matteo-nunziati said in wetting my feet with CM software:
Still, from a more detailed POW: still do you think that having the agent into the image is better than use the ssh approach? I always end up considering that an ssh is always good as a fallback. I'm comparing here Salt master/minion vs Salt-ssh to make that clear.
Yes, not having SSH at all I consider the biggest "slam dunk" for Salt. I see needing to SSH into a machine ever as a bit of a failure now. I don't want SSH to even run, let alone be needed.
wowa that's would be a good article on best practices and "why you need access (and which) to your machine".
My mind set is always:
1- be sure to have local access. (in VM this is the virtual console provided by the hypervisor)
2- be sure to have remote access.
3- implement any other mechanism of communication with the machine (like Salt in this case)but I never close any of the others later. Just keep them as fallback.
btw, remaining on the Ansible/Salt comparison I would like to have an opinion also from @stacksofplates , being he an avid ansible user.
Salt retains remote access, it just gives you a more secure one than SSH. You don't give up remote access, you simply improve it.
-
@matteo-nunziati said in wetting my feet with CM software:
Becaouse my approach is: what is upstream is default, what is mine it is not.
Yes, I understand this, but why? This is universally considered bad from all experience that I have. Your default exists for one purpose - for you. If you are using the upstream default, you are prepping a system that isn't for you. Why? Make it for you! There's no benefit to prepping it for generic use as your goal is to make it for your use, not someone else's.
-
@scottalanmiller said in wetting my feet with CM software:
@matteo-nunziati said in wetting my feet with CM software:
- The first thing to consider as now is that Salt is less available than Ansible in distros’ packages. Moreover, being Ansible backed by Red Hat is possible that they will purge Salt as they done with Xen.
What do you mean purge? Xen is still supported by Red Hat and XenServer is still built on it.
No, there is no Xen support any longer from Red Hat. XenServer being built on CentOS has nothing to do with weather Red Hat will support it or not.
-
@scottalanmiller said in wetting my feet with CM software:
You left out instant commands. Salt can run commands or changes against the environment "instantly", faster than SSH. If something is wrong and you need to push a change or you need to be really tight on the timing of a change, Salt makes this incredibly easy.
This is completely wrong. If you run Ansiblr in parallel it will change every machine at the same time instantly.
-
@stacksofplates said in wetting my feet with CM software:
@scottalanmiller said in wetting my feet with CM software:
@matteo-nunziati said in wetting my feet with CM software:
- The first thing to consider as now is that Salt is less available than Ansible in distros’ packages. Moreover, being Ansible backed by Red Hat is possible that they will purge Salt as they done with Xen.
What do you mean purge? Xen is still supported by Red Hat and XenServer is still built on it.
No, there is no Xen support any longer from Red Hat. XenServer being built on CentOS has nothing to do with weather Red Hat will support it or not.
Ah right, they dropped server side support. They still include the client extensions though.
