This way you can share the config(s) under conf.d between multiple machines using the same roles (or whatever Salt calls them) and have different main NGINX server settings.

@drybjed welcome to the community!!

So I also realized that if you have even a small number of records, a dictionary will become super long. So you can compact the dictionary like this:

records: ns1: {forward: 10.1.30.11, type: A, last: 11, rev: 30.1.10.in-addr.arpa.} ansible: {forward: 10.1.30.5, type: A, last: 5, rev: 30.1.10.in-addr.arpa.}

So while the other way may be easier to read, this saves a TON of space.

@flaxking said in Install NextCloud 11 on Fedora 25 with SaltStack:

@scottalanmiller said in Install NextCloud 11 on Fedora 25 with SaltStack:

@flaxking said in Install NextCloud 11 on Fedora 25 with SaltStack:

@scottalanmiller said in Install NextCloud 11 on Fedora 25 with SaltStack:

@flaxking said in Install NextCloud 11 on Fedora 25 with SaltStack:

@scottalanmiller said in Install NextCloud 11 on Fedora 25 with SaltStack:

Why Fedora 25?

Fedora 25 gives us PHP 7.1 for the latest in features and performance with NextCloud 11. We also get the latest MariaDB and Redis platforms. This helps to speed the overall platform and makes for a snappy experience that gets maximum benefits from a singularly tested and integrated base. The only package that we download and add onto the tested Fedora system here is NextCloud itself. Everything else is fully integrated by the Fedora team.

And Salt 2017.7.2 breaks pkgrepo.managed which would make it harder to add repos with newer versions :(

Unfortunately I'm still doing everything on Ubuntu, which means I have to chase around trying to fulfill dependencies on newer versions that aren't in the default repos

Why stay on Ubuntu?

Because I'm addicted to LXD. While I've heard you can install it on other OSes, I'm pretty sure I would run into some hiccups with things like the Salt LXD formula. So there would be some extra work ahead of me. Alternatively, I could try straight-up LXC or Docker, but that creates some learning prerequisites. Not that I don't like learning, it's just I have other things on the top of my learning priority list.

That doesn't explain it, though. You just install Fedora in your container.

That's a good point, there's no reason why most of my containers couldn't be running Fedora. Mostly I was thinking about switching from Ubuntu to Fedora on my personal laptop first (since there's will be no reason for me to run Ubuntu Desktop without HUD), but it should be pretty simple to switch to fedora containers for my projects and production servers. Thanks for clearing my mind-block!

:) No problem. I do the same thing with Ubuntu as the container host, but we use Fedora for actual workloads.

@dafyre said in Normal Forms of Systems Administration:

@scottalanmiller said in Normal Forms of Systems Administration:

@Tim_G said in Normal Forms of Systems Administration:

So if 4th is strictly using RSAT... would 5th be full automation using SCCM, SCVMM, Orchestrator, and App Controller?

Yes, I believe so. Those would be tools in the Microsoft toolset for that. They tend to take a very different approach than many of their competitors and it's been a while since I've used it. Not sure if SCCM goes all of the way to defined state or just really heavily automated forth form. But I think you can get to that state.

I believe it is properly state defined (fifth form) but not code defined like most of the alternatives.

I think I got lost in all the clutter... but why do you separate Remote GUI from Remote CLI ?

Essentially "automatable interface" vs non-automatable interface. Not that GUIs cannot be automated, but effectively they cannot be.

learned a new English word today.

@wirestyle22 said in How Much Data Do You Have:

@BRRABill said in How Much Data Do You Have:

@scottalanmiller said in How Much Data Do You Have:

@wirestyle22 said in How Much Data Do You Have:

@scottalanmiller said in How Much Data Do You Have:

@wirestyle22 said in How Much Data Do You Have:

@scottalanmiller said in How Much Data Do You Have:

@wirestyle22 said in How Much Data Do You Have:

@scottalanmiller said in How Much Data Do You Have:

@wirestyle22 said in How Much Data Do You Have:

About 20 TB total

What kind of data?

Security Camera videos, Office Data, High Res Imaging (City Planning), Marketing, Documentation, the list goes on

You take backups of security camera video?

It's body worn cameras for police :D

And those are backed up?

they have to be. they can be referred to for decades

Those two things are not related. Have to would be a compliance question. Being referred to for decades is about storage, probably archival, not backup.

You always discus the differences in these terms, but what @wirestyle22 mentioned would be a good thing to start a topic with and do some real world discussions.

It would be difficult because I'm still learning everything here. There are so many sites and they are all using different things. A lot of alternate configurations.

What I meant was ... something like you suggested. Not necessrily YOUR scenario, but sa smilar one.

Security footage that needs to be maintained for 10 years.

What kind of system is @scottalanmiller talking about...

It's true that you can make stateless systems without DevOps tooling and approaches. But the nature and assumptions of those systems is that you cannot. Just letting arbitrary logins (even of administrators) can undermine that. One of the beauties of the pure DevOps model is the lack of logins. Much like functional programming.

@stacksofplates said in What is DevOps?:

@scottalanmiller said in What is DevOps?:

@stacksofplates said in What is DevOps?:

@scottalanmiller said in What is DevOps?:

@stacksofplates said in What is DevOps?:

@scottalanmiller said in What is DevOps?:

@stacksofplates said in What is DevOps?:

@scottalanmiller said in What is DevOps?:

@stacksofplates said in What is DevOps?:

@scottalanmiller said in What is DevOps?:

Two very common SDI tools are Ansible and Salt, but two that are extremely different. Ansible works purely through agents that run on individual servers. Salt uses a central console to control agents. This oversimplifies both, but gives us an idea of the diversity in the way that different systems work.

A common way for smaller shops to work with Ansible is to install agents locally and those agents do nothing more than pull their own configurations from a central Git repository. In this way, in order to manage individual systems, all that needs to be done is for the correct state definition to be stored in the right Git repo. Ansible handles the rest. It looks for updates and applies them when they appear. This is a pure "pull" structure.

Salt works differently. The Salt Master can push commands, almost instantly, to Salt Minions (endpoints.) With salt you can issue traditional commands in real time and see the responses in real time on the master. This makes Salt very powerful for monitoring, in addition to control. State configurations are stored on the Salt Master, rather than on a separate change repository, and when applied can be pushed out instantly to all nodes that are currently online, no need to wait for a polling interval. This is a pure "push" structure.

Ansible is all push through SSH (they have some kind of pull mechanism but I don't think anyone uses it), it doesn't use any agents at all. You can also run commands directly with Ansible. Ad hoc commands are a big help with Ansible, it fixes the weird workarounds you have to use to get sudo to work with remote SSH commands.

Now you just run

ansible host -m shell -a "whatever you need to do" -b -K

One of their big selling points is that you can do pure push, all agent, no server :)

It doesn't use any agents at all. It's all Python. There is no "server" like with Puppet (there is a server in the sense that there is one or multiple machines you do everything from), but there is a machine(s) you push from to other machines.

Servers are typically pull, not push.

No. Agents are pull. The server holds the configs and the agent checks in and pulls the config. Ansible is push and specifically states that on their website.

Not necessarily. Salt is an agent but push. The agent doesn't pull. At least not by default.

It's the exception then. Chef and Puppet both pull. I really like the pull system for CM. I use Ansible for orchestration.

Yup. The push is their huge selling point. No other major player does it. And no open ports either. Doesn't need SSH which is huge.

How does the agent know to interact? Just heartbeat every few seconds?

Open connection. They always talk.

@NashBrydges said in Installing Salt Master:

I'd love to see a category created for all of these how-tos. I'm seriously running an ever growing bookmarks list and would love to be able to just refer to a category to look for these.

All of mine have the how to tag on them.

http://blog.takipi.com/deployment-management-tools-chef-vs-puppet-vs-ansible-vs-saltstack-vs-fabric/

Very interesting, will check that out.

@scottalanmiller said in Red Hat Open Sources Ansible Galaxy:

That's awesome. Now just waiting on Tower, too.

Thought exactly the same: Free/open Tower would be awesome.

That's a nice aspect of systems like Ansible, they basically force good practices like this.

@wirestyle22 I agree... and I like that better than the usual "you look like Anthony Michael Hall."

After signing up, you can go to My Membership to cancel the auto-renewal so you don't forget and get charged.

Updated as I figured out where things have moved away from the documentation that I had. The five minute install video is for Stacki 1.x and they have changed quite a bit at the core so that is why the video does not reflect the needs of the current installer. Avoid the StackiQ video for installation.

So perhaps Red Hat is screwing up the Ansible quality? That's a depressing thought.

@scottalanmiller You should also include cloud-init

https://cloudinit.readthedocs.org/en/latest/

I tried Rundeck. It was more confusing than just using Ansible without a GUI. IMO, just having the playbook with yaml and jinja files is easier to read and use. GUIs always have at least one thing you need in a place you wouldn't think.

I guess I wouldn't mind having some reports in a GUI but I'll stick with just text files.

@johnhooks said:

@scottalanmiller said:

@johnhooks said:

You don't think $5,000 a year for 100 nodes is reasonable?

Not so much, no. When you consider that the assumption is that many of those nodes are $5/mo to operate. That could be nearly 10% of your entire server budget!

lol plus thats the base price with only 30 days of support and no SLA ....

Exactly. Those prices get a bit crazy. $5/year/server would make a lot more sense. There are many cases where I would pay more for Ansible than I would for the server itself!

As long as it is "almost" boring, it is still exciting!