Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2013-06-29

| Channels | #salt index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:21 dthom91 joined #salt
00:22 kleinishere joined #salt
00:37 isomorphic joined #salt
00:42 nrub joined #salt
00:43 rglauser joined #salt
00:45 shiznit joined #salt
00:48 oz_akan_ joined #salt
00:52 jayd3e joined #salt
00:53 jayd3e so I run salt state.highstate.  The best way to gain visibility into what's running is through the salt-run jobs.* commands correct?
00:56 ClausA joined #salt
01:00 karlp or tail the debug log on the minions
01:01 auser joined #salt
01:01 jayd3e karlp: kk,  So far the logs are only showing errors
01:02 jayd3e any way to change it to spit out everything?
01:02 jayd3e err I'll just check the minion config file
01:04 karlp yes :)
01:04 jayd3e haha
01:04 jayd3e karlp: it's a friday dude, want to just come over here and config my servers for me :)
01:05 dthom91 joined #salt
01:12 vmdsch joined #salt
01:33 alazylearner joined #salt
01:33 jalbretsen joined #salt
01:49 fllr joined #salt
01:51 karlp jayd3e: indeed, 2am saturday morning :)
01:52 karlp I'm not really doing much salt mining at home :)
01:53 jayd3e haha it was worth a try
02:01 twiedenbein does anyone know of any github repos where people have configured salt to essentially set up their personal machines from scratch?
02:02 jeddi joined #salt
02:05 auser twiedenbein: funny you mention that
02:05 auser oh, wait… I misunderstood
02:05 auser no, not me
02:05 auser not yet
02:06 alazylearner joined #salt
02:06 Furao personal machines/desktop are so personalized that they even tend to change between each installations. not sure it's really useful to fully automate it trough salt
02:07 Furao but yes, I use salt to deploy sandbox on our OSX dev workstation for a product we developed
02:07 Furao not much different than something on a server
02:08 auser cool Furao
02:09 aranhoide joined #salt
02:16 opapo joined #salt
02:19 twiedenbein Furao: oh, I agree
02:19 rberger joined #salt
02:19 twiedenbein i'm just interested in seeing examples where people have managed aspects of their personal machines
02:26 bluemoon joined #salt
02:28 Furao how you guys say in english the sort of dried blood that happens on a wound after a while?
02:28 Furao like a big cut on the skin
02:28 Furao I just know the words for that in other languages slangs
02:28 twiedenbein uhh, like a blood clot?
02:28 twiedenbein or like a scab
02:29 Furao scab! thanks
02:33 SEJeff_work joined #salt
02:34 kleinishere joined #salt
02:36 kmwhite joined #salt
02:37 luminous Furao: it totally makes sense to automate desktops!
02:37 luminous what you note is exactly why I would
02:38 luminous s/would/do
02:38 luminous though I haven't gotten to spend enough time with salt on openbs :(
02:38 luminous *openbsd
02:38 bluemoon joined #salt
02:40 raydeo joined #salt
02:40 luminous twiedenbein: in many ways, automating desktops is easier... you have a longer list of packages (put in pillar!), more files to manage (but that's easy), fewer services or states with weird cmd.run, and then home in git... done
02:43 Furao luminous: well some part of it.
02:43 Furao let's write a porn downloader state
02:44 jessep joined #salt
02:45 Furao I heard Thomas said something about Android support for salt
02:49 Furao something:
02:50 Furao - state.alias:
02:50 Furao - require:
02:50 Furao - pkg: else
02:50 Furao - cmd: other
02:50 Furao and in your state use - require: - state: something
02:50 luminous O.o
02:50 kleinishere joined #salt
02:51 Furao we need that
02:51 Furao maybe not state, maybe alias
02:51 Furao I don't know
02:51 luminous ok
02:51 kmwhite left #salt
02:51 * luminous doesn't follow, but that's ok
02:51 Furao ahaha
02:51 Furao let me show an example
02:51 jayd3e how do you specify which user needs to actually run the command.  So for example, I want most things to be run as root, but I need a select few(such as checking out a git repo) as a specific user
02:52 luminous you just did :P
02:52 luminous jayd3e: that's a good question
02:52 jayd3e luminous: why thank you, any ideas?
02:52 luminous you might need to call salt separately, as that user, to run that state
02:53 jayd3e luminous: icic
02:53 luminous else, the hackish way is to run a cmd.run with an su -l
02:53 luminous but there may be a proper way that I don't know
02:53 luminous you'd be surprised what these folks come up with..
02:53 jayd3e there is a runas option for the git state
02:54 luminous well there you go!
02:54 jayd3e pretty sure that will work for me
02:54 luminous i ought to have known that ><
02:54 luminous I have looked at / used that
02:55 luminous runas ought to be added / made available to all states, like requisites
02:56 jessep joined #salt
02:58 Furao luminous: https://gist.github.com/bclermont/2f83b8208b2abcf323dc
03:00 LarsN any salt-cloud ninjas around these parts tonight?
03:00 luminous depends on what you are doing..
03:00 luminous or rather, I'm no ninja as I'd like, but certainly one inm training ;)
03:00 LarsN http://pastebin.com/ghHQZA3i
03:00 Furao jayd3e: you can just run as root and then chown after?
03:01 Furao some states might not support runas
03:01 LarsN so that's an excerpt from my cloud.profiles
03:02 LarsN I'm wondering if there's any more efficient way to add the Region/AZ grains.
03:02 luminous Furao: eh, that's a bit to much of a headache for me.. I think I would rather take the approach to have a software1.osx and a software.linux statess
03:02 jayd3e Furao: yah I could, I'm finding there are quite a few ways to specify which user is actually running the command
03:02 LarsN I figure somewhere I'm going to have to have a "large pile of possible "types""
03:02 * luminous looks
03:02 LarsN whether it's in profiles, or groups, or states, somewhere I think I'm gonig to have to bite the bullet.
03:03 Furao luminous: my method allow you to save probably a lot of lines, reuse the deployment logic and just change a little bit based on some condition
03:04 luminous Furao: my method simply stuffs the system-specific stuff in a state of their own, at the expense of some duplication. I'm ok with the duplication if it is small and is outweighed by readability
03:04 luminous but I like your approach for whenm it is not
03:04 Furao luminous: in my case, this is not for OS version reason, it's because I do have a mirror of many packages (in case github, pip or others are down) so if some value is defined in my pillars, the minion download the file from the mirror instead from public internet. but sometimes the state used to install this is changed. 99% else is the same
03:04 luminous LarsN: I'm not sure I'm forseeing what you are
03:05 LarsN so we have 3 classes of instances we're trying to generate
03:05 LarsN across three regions
03:05 luminous 3 roles?
03:05 LarsN across three availability zones per region.
03:05 luminous s/roles/classes ?
03:05 fllr joined #salt
03:05 LarsN in each "class" of machine there's potentially 2 roles per class it could fill
03:05 luminous ah
03:06 luminous ok, so you have 4 roles
03:06 luminous what's the problem?
03:06 Furao I define my roles in pillars
03:06 * luminous too
03:07 luminous but still, let's hear what the problem is
03:07 LarsN well, I'm planning on using grains on the instances to designate what state files (with some jinja magic) get rolled out to the far end.
03:07 Furao top.sls loop in pillar and include proper role.$rolename
03:07 luminous maybe you like grains
03:07 vmdsch joined #salt
03:07 Furao pillars is better for that
03:07 luminous LarsN: pillar can be used too
03:07 vmdsch left #salt
03:07 luminous overall, pillar is a bit more fun/flexible to use
03:08 LarsN in the cloud.profiles I see 18 profiles currently
03:08 luminous overall I have found a cleaner setup with as much as possible stuffed into pillar
03:08 * luminous wants his cloud.profiles in a webui
03:08 luminous I'm a bit tired of not having that integration
03:09 luminous though I've scoped out what this would take ;)
03:10 luminous LarsN: why so many profiles?
03:10 luminous you have 4 roles of supposedly identical systems
03:10 luminous even with dev/etc... that seems like a lot
03:10 LarsN in three regions
03:10 LarsN and three AZs per region
03:11 LarsN so the profiles have to call appropriate cloud.providers
03:11 luminous salt-cloud needs a simper way of expressimng that
03:11 luminous overall though.. we're not really into ninja territory yet
03:11 luminous :p
03:11 LarsN fair enough
03:11 LarsN we might not be doing it wrong, yet
03:11 LarsN :)
03:12 LarsN I'm trying to avoid making stupid decisions early on.
03:12 LarsN so I'm not stuck with them forever after. :)
03:12 luminous so far I think you're within reason, given how salt-cloud is setup
03:12 luminous yea, well keep in mind that salt-cloud will continue to evolve
03:12 luminous so you will likely be changing things..
03:13 LarsN yeah, I figured
03:13 luminous also, maybe consider something other than AWS?
03:13 luminous :P
03:13 LarsN still better to plan well up front
03:13 LarsN I work for HP Cloud actually
03:13 luminous oh yea, I agree
03:13 LarsN and we're building test instances for our cloud...
03:13 LarsN so...
03:13 luminous ahhh
03:13 * luminous has a message for the higher ups..
03:13 luminous let your shit run on other systems
03:14 * luminous end rant
03:14 clone1018 joined #salt
03:14 luminous LarsN: if you want ninja territory... remember that the profiles/maps/etc/configs are just data dicts.. so you can construct them programmatically and call salt-cloud
03:15 LarsN luminous: that's on the roadmap,
03:15 LarsN well, maps are anyway
03:15 luminous maps are awesome
03:15 LarsN figure we need to start with a foundation
03:15 luminous I think this is what I'd do to build a webui
03:15 LarsN and then start building the house.
03:16 luminous or have a webui control salt-cloud with profiles stored somewhere other than a file
03:16 luminous the other
03:16 luminous hack, is to have a cloud.profiles as a template, and render it with jinja/etc, pulling text blocks from db/etc
03:18 UtahDave joined #salt
03:18 * luminous waves
03:19 * luminous hides the booze
03:19 LarsN UtahDave: sorry for not touching base yesterday.  This site is one of those "secure" locations, I couldn't convince them otherwise.
03:19 LarsN :(
03:19 luminous hah
03:19 luminous that's why you have ssh tunnels and IRC from elsewhere
03:19 UtahDave LarsN: Ah, that's cool.  Thanks for checking!
03:19 LarsN luminous: this would ahve been for an in-person hackathon
03:20 LarsN UtahDave: I might get involved tomorrow virtually tomorrow.
03:20 luminous ah
03:20 UtahDave LarsN: that's cool!
03:20 luminous UtahDave: couldn't get enough of #salt for the week?
03:20 luminous :PO
03:20 UtahDave luminous: :)   I'm an addict!    lol
03:20 * luminous pours UtahDave a martini
03:20 luminous got some salt?
03:21 * luminous should be writing code...
03:21 UtahDave :)  How many martinis have you had tonight??
03:21 LarsN I had a P.Terry's burger
03:21 LarsN and plan on picking up Torchy's on my way into work tomorrow.
03:21 luminous eh, I'm not really one for the booze actually
03:21 luminous but I can tend :P
03:22 LarsN is it weird I brew beer, but don't drink much beer?
03:22 luminous http://www.funraniumlabs.com/2013/06/alcoholism-in-antarctica <<< hilarious / awesome read
03:22 luminous nah
03:22 UtahDave luminous: nice
03:22 UtahDave LarsN: Hmm. Torchy's
03:22 luminous but you ought to consider brewing living elixirs instead
03:22 LarsN UtahDave: how long before you relocate to Austin?
03:22 LarsN ;)
03:23 LarsN luminous: like Kombucha?
03:23 luminous too hot
03:23 LarsN luminous: but... Torchys
03:23 luminous I guess, but no, I'm thinking even more awesome
03:23 * luminous shrugs
03:23 luminous I'm weird and don't indulge in eating out anymore
03:24 luminous I actually haven't traveled more than a mile in ~9 months
03:24 UtahDave LarsN: :)  Austin was pretty nice!  I could be tempted to do so.
03:25 luminous LarsN: RE elixirs, I was thinking more like a champagne-based herbal concoction. I've known many folks to make them, and they are a world of wonder
03:26 luminous especially if you toss in some fruits from your orchard
03:26 luminous mmmmmmm
03:27 luminous the fact that it is living, and not yeast-based.. these change everything about the drink. though it may not seem like much
03:27 * luminous is so add.
03:27 luminous code.code.code.
03:27 * luminous hides
03:28 fllr joined #salt
03:32 LarsN I'm sure this is covered somewhere but I'm drawing a blank
03:32 LarsN how would I go about removing a custom grain & it's value
03:32 LarsN second.
03:33 LarsN how would I go about adding a custome grain with multiple values (similar to the IPv4 grain)
03:33 luminous to salt-cloud profile?
03:33 LarsN no
03:33 LarsN just to an minion managed by salt.
03:33 luminous can you use pillar instead?
03:33 fllr joined #salt
03:34 LarsN I accidentally added
03:34 LarsN surly: [city: Austin] [state: Texas]
03:34 LarsN rather than
03:34 luminous what's the logical case for grain?
03:34 LarsN city: Austin
03:34 LarsN state: Texas
03:34 * luminous prefers to have all details in one place
03:34 luminous rather than split across pillar and grainms
03:34 luminous but that is me
03:35 LarsN I use grains, outside of work, for things like
03:35 LarsN http://pastebin.com/GyXMJBfU
03:36 UtahDave LarsN: Do you want to do that manually or from the cli on the master?
03:36 LarsN UtahDave: I'm sitting in front of the minion, and am ssh'd to the master in this test case.
03:37 LarsN so it doesn't matter :)
03:37 LarsN I also have a location grain I added during TLF I figure I can nuke.
03:38 terminalmage joined #salt
03:38 UtahDave ok, so if you're adding it to a grains file or the minion's config, then it's just a regular yaml dictionary or list
03:38 StDiluted joined #salt
03:39 UtahDave from the master you'd use grains.setval          let me find an example
03:39 LarsN So I figured out how to set a single value to a grain.
03:39 LarsN salt "surly" grains.setval "city" "Austin"
03:40 UtahDave sudo salt 'dave*' grains.setval zzz ['test','test2']
03:40 LarsN but if I wanted "cities" "Austin<cr>" "Milwaukee<cr>" "Indianapolis<cr>"
03:40 LarsN I'm drawing a blank.
03:40 LarsN ahhh
03:40 UtahDave I just test that.  that creates a list.
03:40 UtahDave I'm pretty sure you can do a dictionary, too.  Let me try
03:42 whit joined #salt
03:42 LarsN salt "surly" grains.setval cities ['Milwaukee','Austin','Indianapolis']
03:42 LarsN works as expected.
03:42 LarsN how do I go about removing grains
03:43 luminous is there a grains.delval?
03:43 LarsN grains.get     grains.item    grains.items   grains.ls      grains.setval
03:43 UtahDave no, there's not a grains.del, it looks like
03:43 luminous restart the minion if the grain isn't set in a file?
03:43 * luminous is not sure
03:44 UtahDave LarsN: I guess for now you can set the grain to an empty string.  Seems like there should be a way to remove them.
03:44 luminous the idea is that grains are more set in stone (per running minino)
03:44 UtahDave I think that's an oversight.  Probably time for a new issue on github.
03:44 luminous no?
03:44 luminous hah
03:45 UtahDave luminous: Yes, grains are generally pretty static.
03:45 luminous grains.delete
03:45 luminous seems reasonable request, given the others
03:48 Furao UtahDave: what do you think of that https://gist.github.com/bclermont/2f83b8208b2abcf323dc ?
03:48 UtahDave luminous: I agree
03:48 lightsey joined #salt
03:48 UtahDave Furao: looking
03:49 UtahDave Furao: that looks pretty good to me.  Is that working for you?
03:49 Furao instead of an alias, I was thinking of a state that does nothing.
03:50 Furao UtahDave: no, because alias don't exists! but it was just something that might be useful to some
03:50 isomorphic joined #salt
03:50 Furao as a way to make it easier to handle requirements base on some conditions
03:51 Furao oh… alias exists but for email
03:53 alazylearner joined #salt
03:53 Furao but it's just some way to define a list of requirements under a single state, and keep all {% if elif else %} conditions under a single declaration
03:54 jayd3e joined #salt
03:54 luminous yea that would be nice
03:54 Furao luminous: and that don't make thing less readable as you define in a single statement all the OS (or other conditions) specifics
03:54 Furao it's probably better than 99% duplication
03:55 Furao and duplication in separate .sls file don't solve requirements over other .sls files that include: - state.$osspecific
03:55 ninkotech joined #salt
03:56 UtahDave Furao: I think you can already do this
03:56 UtahDave just a sec
03:56 Furao that and this https://github.com/saltstack/salt/issues/4357 I can remove 30-40% of my templates and .sls files
03:57 UtahDave Furao: I think this extend declaration might help you    http://docs.saltstack.com/topics/tutorials/states_pt3.html#extend-declaration
03:57 Furao in term of LOC
03:58 UtahDave Furao: Do you know of many Salt users around where you live?
03:58 Psi-Jack Hmmm
03:59 Furao UtahDave: no, but I started the propaganda. someone in Kuala Lumpur told me that some of his co-workers asked about salt (they're actually using puppet)
04:00 Furao I will do a presentation of salt to a Python LUG in KL and I'll try to make one in Singapore too
04:00 UtahDave Furao: That's cool.
04:00 UtahDave I don't know if you've heard, but we're going to have a big distributed Salt Sprint hackathon on July 27th.
04:01 UtahDave I was wondering if there would be enough interest out there to put a small group together
04:01 Furao no didn't heard of that.
04:01 Furao I hired a full salt guy a few months ago
04:01 Furao and he's coming today here for one month
04:01 Furao and he's coming back home july 27 :)
04:01 Furao no avail for him
04:01 Furao full -> fulltime
04:02 UtahDave Ah, that's cool.  congrats.
04:03 UtahDave nice to hear about Salt jobs.   :)
04:03 UtahDave Well, I better get off my computer. Wife wants me to watch a movie with her
04:03 UtahDave Talk to you all later.
04:03 Furao good movie! bye
04:04 luminous :)
04:04 Furao I think I didn't explained it well. because extends don't do that
04:05 Furao still need the same {% if elif else %}
04:05 luminous write a ticket
04:06 Psi-Jack Specified SLS purpose in environment base is not available on the salt master
04:07 Psi-Jack I'm trying to use my pillar/top.sls to define role/classification on nodes for targeting purposes and grouping.
04:08 aranhoide left #salt
04:12 jessep joined #salt
04:13 Furao Psi-Jack: here is my top.sls
04:13 Furao {% if pillar['branch']|default('base') == 'master' %}base{% else %}{{ pillar['branch']|default('base') }}{% endif %}:
04:13 Furao '*':
04:13 Furao {% for role in pillar['global_roles'] %}
04:13 Furao {% if role in pillar['roles']|default([]) %}
04:13 Furao - roles.{{ role }}
04:13 Furao {% else %}
04:13 Furao - roles.{{ role }}.absent
04:13 Furao {% endif %}
04:13 Furao {% endfor %}
04:13 Furao it handle roles and environment (trough gitfs branches)
04:13 robawt wuddup
04:14 Psi-Jack Uhh... yeah... That's just crazy looking, and stuff. :)
04:22 Psi-Jack http://pastebin.ca/2411440   -- That's what's giving me this error: Specified SLS fw in environment firewall is not available on the salt master
04:23 Psi-Jack base's data.sls works, and it's just the basic data.sls from the salt tutorial, useless data at the moment, but functional to show it's working and the data is viewable.
04:25 alazylearner joined #salt
04:27 ninkotech joined #salt
04:27 jimallman joined #salt
04:29 scooby2 joined #salt
04:33 Furao it can't find fw.sls
04:33 Furao weird
04:33 Psi-Jack or fw/init.sls
04:37 fllr So, I'm going through the salt walkthrough(this is my first time trying salt) and it's telling me to setup a master, but where would that master go? My local machine?
04:38 robawt fllr: any machine that can access the future minions on the same network
04:40 luminous fllr: you don't require a master, though it depends on what you want to do
04:41 luminous what are you looking to have salt do for you?
04:41 fllr set my vagrant box, and eventually deploy my code to my machines.
04:41 fllr luminous:
04:42 jasonrm Furao: how do you populate your pillar['roles'] in pillar?
04:42 luminous fllr: ok, so check out salty-vagrant too
04:43 luminous you could run salt entirely locally ifyou wanted, applying states with salt-call, or run a master as a vm or on your host, and provision / remote exec on minions that way
04:43 luminous it's up to you
04:44 robawt salty vagrant rocks
04:45 robawt it's a really great way to write salt states when you don't have a vps available
04:45 Furao jasonrm: depends, it's either static in the pillars, or an ext_pillars module that query an inventory system
04:45 robawt you can make your states a git repo and just import the repo to the diff masters
04:46 fllr Oh, so you guys recommend salty vagrant? Cause when I googled I found two projects, and ended up going with vagrant-salt, as opposed to salty-vagrant...
04:46 fllr I'm gonna try that out...
04:46 robawt fllr: i put a convenience git repo together for salty-vagrant
04:47 robawt it was something i put together to let some folks at work have a jump off point
04:47 robawt are you running ubuntu?
04:47 fllr robawt: Yeah. Do you have a link?
04:47 robawt sure
04:48 EugeneKay I prefer my hobos with sugar.
04:48 joehh joined #salt
04:49 robawt fllr: pm
04:51 jasonrm Furao: for now I'm just trying to do it based on minion id. I'm wanting to use the newly added ext_pillar git module, however that isn't working out too smoothly for me quite yet.  oh well, will just have to keep trying things.
04:52 kenbolton joined #salt
04:53 MasterNayru joined #salt
04:53 akoumjian fllr: There is one old project, but salty-vagrant's ruby gem name is vagrant-salt
04:53 robawt speak of the devil
04:53 robawt wuddup akoumjian
04:54 akoumjian How's it going robawt
04:54 robawt akoumjian: very well, how are you?
04:54 akoumjian robawt: Also very well.
04:55 Furao jasonrm: is that you that wrote that ext_pillar git module?
04:55 Furao this was added yesterday
04:55 jasonrm Furao: nope
04:58 jasonrm Furao: I was actually thinking about trying to today, which is how I came across it. Glad it was there, because my python is, well, lacking. I've only tinkered around some with the brew and launchd modules/states
04:58 kleinishere joined #salt
04:59 Furao you should wait a little bit before trying ext_pillar git
05:03 jasonrm yeah, it is a bit fresh. Had to modify the src to work so I'll be holding for for a bit, but I am glad to see it make an appearance finally.
05:05 Furao joined #salt
05:14 linjan joined #salt
05:14 nrub joined #salt
05:18 quantumsummers|c Interested in any feedback, like does this need any code comments at all https://github.com/saltstack/salt/issues/5822
05:18 quantumsummers|c if you use gentoo, it may matter to you
05:29 Psi-Jack Furao: That's also from pillar.data, BTW, from earlier.
05:30 Psi-Jack When I specifically look for grains I setup in a few minions, I see them in grains.items.
05:30 auser joined #salt
05:35 jessep joined #salt
05:47 rglauser joined #salt
05:48 fllr joined #salt
06:01 ninkotech joined #salt
06:27 chjohnst_work joined #salt
07:01 rberger left #salt
07:16 indymike_ joined #salt
07:17 esrax_ joined #salt
07:18 probably1ine joined #salt
07:18 kvbik_ joined #salt
07:18 farrab joined #salt
07:18 txmoose_ joined #salt
07:18 insatsu_ joined #salt
07:18 necronia- joined #salt
07:18 whiteinge joined #salt
07:18 keith4 joined #salt
07:18 SEJeff_work joined #salt
07:19 copec joined #salt
07:19 JimShoe joined #salt
07:19 zz___number5__ joined #salt
07:19 Psi-Jack joined #salt
07:19 copec joined #salt
07:19 marcinkuzminski joined #salt
07:19 ninkotech joined #salt
07:20 zloidemon joined #salt
07:20 copec joined #salt
07:20 henk joined #salt
07:20 pyeek_ joined #salt
07:20 copec joined #salt
07:21 copec joined #salt
07:21 jalbretsen joined #salt
07:21 copec joined #salt
07:22 copec joined #salt
07:22 copec joined #salt
07:23 antsygeek joined #salt
07:23 copec joined #salt
07:23 copec joined #salt
07:24 copec joined #salt
07:24 copec joined #salt
07:25 copec joined #salt
07:25 copec joined #salt
07:26 copec joined #salt
07:26 copec joined #salt
07:27 copec joined #salt
07:27 copec joined #salt
07:28 copec joined #salt
07:28 copec joined #salt
07:29 copec joined #salt
07:29 copec joined #salt
07:30 copec joined #salt
07:30 copec joined #salt
07:31 copec joined #salt
07:31 copec joined #salt
07:32 copec joined #salt
07:32 copec joined #salt
07:33 copec joined #salt
07:33 copec joined #salt
07:34 copec joined #salt
07:39 yidhra joined #salt
07:52 ninkotech joined #salt
07:53 berto- joined #salt
07:57 xinkeT joined #salt
07:59 ronc joined #salt
08:00 koolhead17 joined #salt
08:14 austin_laptop joined #salt
08:16 oliv_mc left #salt
08:24 zonk1024 joined #salt
08:31 dthom91 joined #salt
08:38 isomorphic joined #salt
08:41 jefferai joined #salt
08:45 jefferai joined #salt
09:02 Vivek joined #salt
09:06 berto- joined #salt
09:31 xet7 joined #salt
09:58 nrub joined #salt
09:59 ninkotech joined #salt
10:10 JordanRinke Random question for anyone has had to deal with it. how are you handling mulit-tenancy? I am working with some startup accelerators. They all have their own domains but only need a few similar systems. Running a salt master for each seems like a waste, so running a single one for the whole accelerator seems best
10:11 JordanRinke but then how does on manage systems from multiple domains/users etc. Maybe it is in the docs and I am just missing it?
10:15 blast_hardcheese JordanRinke: Why not just have administrators for the different accelerators be \*.theirdomain ?
10:16 blast_hardcheese I've never done this, but it looks like it's possible given http://docs.saltstack.com/topics/eauth/access_control.html
10:16 Nexpro joined #salt
10:18 JordanRinke Guess I need to play with it, to me it looked like I had to specify each thing they could do
10:18 JordanRinke if I could say they can do an ything on *.domain.com then that would be a good first step
10:20 JordanRinke Wonder how far away a multi-tenant or hosted solution is
10:26 scooby2 joined #salt
10:30 blast_hardcheese JordanRinke: Look at the last example on the page I linked,
10:30 blast_hardcheese "It also allows steve unrestricted access to salt commands."
10:33 dshea joined #salt
10:33 blast_hardcheese JordanRinke: I would assume you could do something with client_acl like: https://gist.github.com/blast-hardcheese/5e71ae7f02f4d8a8a26d
10:33 blast_hardcheese I'm not positive, but that would be where I'd start looking.
10:33 blast_hardcheese I need ot get some food though, good luck!
10:33 JordanRinke blast_hardcheese: Ah, so I could do *.domain.com - .*
10:34 JordanRinke thanks, have fun
10:35 xet7 joined #salt
10:36 hazzadous joined #salt
10:42 link0 joined #salt
10:55 jeddi JordanRinke: i haven't really looked at this, or thought much about it, but could you partition things based on git - having several repositories under /srv/salt that different tenants have control over?   it may be possible to set that up securely, but maybe not.
10:56 jeddi though i think i'd probably go for the multiple masters, and just share common config entities, mostly as it seems to guarantee a better security model.
11:00 cxz joined #salt
11:02 lemao joined #salt
11:10 jpadilla joined #salt
11:13 JordanRinke jeddi: yeah, having the git repos seems reasonable. I think you might be right though, I have a feeling that people are going to want customizations the moment they start using the platform
11:14 JordanRinke I might just do something with LXC containers in a VM. The salt masters are so light weight, I don't think there would be an issue cramming a bunch into a VM - we will see I guess
11:17 JordanRinke Yeah, I think that might work. LXC containers on a VM with CNAME DNS entries for salt, and then just assign custom ports to each salt master
11:20 jeddi JordanRinke: i'm in a vaguely similar position, but with a small number of clients whose machines we manage for them.  for succession planning it'd be nice to keep things *logically* partitioned in such a way that if they move to in-house support, say, I can separate out their bits from our and our other client's bits.
11:20 jeddi if you want to get nicely meta you could provision each client's salt configuration via salt-cloud :)   don't think it does lxc provisioning just yet though.
11:21 JordanRinke jeddi: well it does openstack, and openstack has a lxc driver now, but then I am running an AIO openstack install, etc etc.
11:21 jeddi oh, really?  inneressing - i shall have to explore this.  i've used salt-cloud for openstack/rackspace, and have been podnering a good use case to explore lxc with.
11:22 JordanRinke jeddi: You bring up a good point though, I should assume/hope these startups will grow into their own stuff. Them having their *own* systems will make it easier for them to spread their things
11:22 JordanRinke spread their wings*
11:23 jeddi JordanRinke: yeah, that's the most compelling thing for me right now - i'd love to be able to hand back their systems *and* the management of them in one cheerful bundle.   at the moment that's not terribly easy to do because it's intermingled.   either approach is going to be a tradeoff, i guess.
11:24 jeddi JordanRinke: in practice you've also got the problem of effectively forcing salt onto them, but translating yaml rulesets is goign to be easier than reverse-engineering running systems and/or trusting a wiki or changelog.
11:24 JordanRinke jeddi: re: openstack - it uses libvirt for a lot of stuff, and in the last year libvirts control of LXC has gotten a lot better, if you have experience running openstack installations now you literally just change the libvirt_type=lxc
11:24 JordanRinke I think there are some limitations, but for simple instances you shouldn't need to do much else
11:25 jeddi JordanRinke: ooh, nice.  i hit a contention with debian's libvirt / virt-manager that's apparently a known bug with older vm's or some such - the presence of sys/fs/cgroups can break the starting of some kvm instances.   i need to re-explore this.
11:26 jeddi i also need to get my head around how you handle networking if you run some containers up on a rackspace instance, say .. i'm assuming you have to start NATing via the vps.
11:28 JordanRinke <- Racker/Stacker ... so feel free to ask questions
11:29 jeddi ooh - lovely!   unfortunately i don't yet know enough about what i want to do ... to have any sensible questions :)
11:34 hotbox joined #salt
11:36 JordanRinke Well if you have any, I idle in here or shoot me an email jordan@rackspace.com
11:39 hotbox joined #salt
11:40 ninkotech joined #salt
11:42 emocakes joined #salt
11:51 Teknix joined #salt
12:02 diegows joined #salt
12:02 zooz joined #salt
12:05 koolhead17 joined #salt
12:07 waverider joined #salt
12:08 waverider left #salt
12:10 xinkeT joined #salt
12:23 jeddi joined #salt
12:26 azbarcea joined #salt
12:29 Psi-Jack Hmmm.. So I'm trying to work with hierarchical variables, to a very low scale, mainly to set pillar data for specified systems, and for everything else, having default settings. Doing this for an ntp state. It seems though, when base and '*' have - ntp, no matter what, there's no chance in manipulating the pillar information from anything provided from that ntp pillar state.
12:34 bhosmer joined #salt
12:36 f4cl3y joined #salt
12:36 f4cl3y joined #salt
12:49 bhosmer joined #salt
12:52 txmoose_ Howdy everyone.  I know I'm going to feel incredibly dumb when I ask this, but this is frustrating me to no end.  I have a master and 4 minions.  One minion is along side the master.  That is the only minion my master is not seeing with salt-key -L.
12:52 txmoose_ I've tried everything from having it connect to localhost to 127.0.0.1 to the actual IP address and it still won't see.
12:52 txmoose_ Running the minion in debug shows no troubles.  Can someone point me in a direction to get this thing talking to the master process please?
13:04 jeddi txmoose: watching the log on the master suggests that it's not seeing anything i'm guessing?   if you 'ping salt' from the master, what does it resolve to?   did you change the master: value in the master:/etc/salt/minion file?
13:04 jeddi txmoose: you could delete the keys for the master's minion and try to renegotiate.
13:04 jeddi (though i suspect that'll fail int he same way it's failing now)
13:05 txmoose I already tried deleting keys.  For sake of discussion, the master server's hostname is 'archon'.  It should also find that as the minion's name.
13:06 txmoose But there's no public key for 'archon' in /etc/salt/pki/master/<anything>
13:06 txmoose At this moment, the minion ON THE MASTER server is set to look for a master at 127.0.0.1
13:08 joehh joined #salt
13:09 Psi-Jack Ahhhh... So pillar's top.sls does cascade down. First match takes precedence over others.
13:11 Psi-Jack So, if I stack 'roles:ntp-server': - ntp/server.sls; then below that have '*': - ntp  -- The server.sls will overrule whatever the ntp.sls has if they share the same master key.
13:11 jeddi txmoose: on the master can you 'telnet 127.0.0.1 4505'  and also to port 4506
13:12 jeddi i think salt/zmq listens on both ports on all interfaces, but i've never tried configuring the thing to talk to localhost.
13:12 txmoose It's trying, but not going anywhere in a hurry
13:12 jeddi oh - so you don't get the Connected to .. ?
13:13 jeddi can you try 'telnet {public-ip} 4505' to confirm that that works?
13:13 txmoose I'm trying that now
13:13 txmoose nothing
13:13 jeddi sorry.
13:13 txmoose still 'Trying <ipaddress> ...'
13:13 jeddi but from one of your other minions you can see a Connected message from a telnet/
13:13 jeddi (guessing yu're also trying that now :)
13:14 jeddi you didn't chaneg port #'s in master, but will ask just in case?
13:14 Psi-Jack Sounds like... local firewall, or selinux.
13:14 jeddi only one public ip on that box?
13:14 txmoose no selinux and firewall is open properly
13:14 txmoose yes, sir only one IP
13:14 txmoose and no, didn't change port numbers
13:15 jeddi as i say, i'm pretty sure it binds to all interfaces .. and the other boxes are talking to it okay .. which is a bit weird, if you're trying to come in via the same interface that they are.
13:15 Psi-Jack "Trying <ipaddress> ..." and then taking a long time means it's not actively being refused, but most likely being dropped silently.
13:15 jeddi can you tail syslog while you're doing these telnets?
13:15 jeddi and/or run 'iptables --list -n' and see if anything looks obviously suspicious.  or suspiciously obvious.
13:16 jeddi Psi-Jack: yeah .. it's sounding like a vanilla networking problem.  selinux always irritates me.  almost as much as apparmour.
13:16 Psi-Jack Almost? heh., SELinux irritates me more than anything. I could actually stand AppArmor.
13:17 jeddi txmoose: do you have fail2ban installed?  it might be coming into play (i've had similar issues previously where denyhosts will lock me out .. often not something you anticipate).  check /etc/hosts.deny JIC.
13:18 txmoose jeddi: yes, I do actually, but it's only checking port 22
13:18 jeddi apparmor is the first entry in my stanza in base.sls to REMOVE FROM EVERY MACHINE>
13:18 Psi-Jack Eh, fail2ban doesn't check ports. Just logfiles. :)
13:18 jeddi txmoose: you'll have fun sorting this out, either way ;)
13:18 jeddi Psi-Jack: i don't know if fail2ban checks salt logs, though, yet, by default?  i'm guessing probably not.
13:18 Psi-Jack not likely, no.
13:18 txmoose You can write a jail for it
13:18 txmoose But I don't
13:19 txmoose because I'm lazy :P
13:19 jeddi i've noticed salt logs can be a bit noisy when they're first trying to shake hands between master and minion.
13:19 Psi-Jack yeah, I hate fail2ban. I wrote my own engine that doesn't just sit there and poll logfiles. It live streams them in. :)
13:19 jeddi i usually rely on denyhosts rathr than fail2ban .. modest needs.
13:19 txmoose Interesting side note:  Just ran 'salt '*' test.ping' and it failed for the 3 servers that I was able to accept keys for.
13:20 jeddi txmoose: inneressing.  and you said the minions could telnet to 4505 / 4506 on the master?
13:20 txmoose Yes, sir, but the escape character gets ignored so I have to kill the shell to get out of the telnet
13:20 txmoose I think I might have something broken
13:20 jeddi you can do ctrl ]
13:20 jeddi and then 'quit'
13:20 jeddi you don't need to kill the shell :)
13:21 txmoose Good to know, thank you.
13:21 jeddi i know that's escape .. but it usually works reliably more so than 'esc' per se.  (which id on't think works on telnets that are hanging?)
13:22 jeddi txmoose: something broken .. is almost guaranteed an accurate assessment. :)    i really can't help beyond here as i don't use selinux or similar - mostly for erasons like this.  did 'iptables --list -n' show that you had some rules in play btw?
13:24 Psi-Jack Huh.. Well..
13:24 txmoose SELinux is disabled
13:24 txmoose I hate it
13:25 Psi-Jack Seems like the better option is just simply to make my pillar/ntp/init.sls just programatically target a node for specific differences. :/
13:25 emocakes left #salt
13:28 txmoose I feel as though I'm getting farther from where I want to be on this...
13:31 txmoose nothing is talking...
13:33 Psi-Jack Well, it looks to me like salt-minions don't listen on any port, they don't bind.
13:33 Psi-Jack salt-master binds to 4505 and 4506, itself, and the salt-minions just connect to the salt-master persistently.
13:33 jeddi Psi-Jack: that's my understanding too.
13:33 jeddi http://docs.saltstack.com/topics/troubleshooting/index.html
13:34 jeddi txmoose: and iptables?
13:34 Psi-Jack And just to be sane, getenforce shows Permissive or Disabled?
13:34 jeddi actually, how many salt masters are you running?  i've seen people in here talk of Weird Happenings when they accidentally run two salt-matsers.
13:35 txmoose jeddi: thanks.  And iptables is good to go... 4505/6 only need to be open on the master, yes?
13:35 Psi-Jack jeddi: heh, which is interesting, With 0.16.0 coming allowing for master-master.
13:35 jeddi txmoose: yes.
13:35 txmoose jeddi: 1 master, 4 minions, 4 servers total.
13:35 jeddi Psi-Jack: ah, yeah, that'll be fun.  and evidently transparent (ie. ignorable) for single-master systems :)
13:36 Psi-Jack I'm still heavily learning salt, but so far, it's looking capable of doing what I need, just need to learn best tactics of how to do things, like hierarchical structuring of pillar data and states.
13:37 jeddi best practices are a noticably lacking commodity in the docs.
13:37 Psi-Jack Preferrably, the hierarchical part not looking so much like code, but structure. That seems to be my current failing point.
13:38 jeddi Psi-Jack: much empathy.  i'm about to dive into the task of moving much of my accumulated cruft - specifically managing users and grants for mysql - out of states and into pillars.   just working out what to outer and inner loop on - users or tables, basically - is giving me grief.  i reason i can re-factor later ... as much as i hate the idea of revisiting code.
13:38 Psi-Jack Such as: https://github.com/saltstack-formulas/ntp/blob/master/formula2/ntp/pillardata/ntp.sls
13:39 Psi-Jack jeddi: Heh, I'm soon to be moving ~200 servers from puppet, to salt.
13:39 jeddi wow.
13:39 jeddi are the pp's all your own making?
13:39 jeddi i can't imagine much worse a task than trying to translate someone else's manifests into salty yaml :)
13:39 Psi-Jack jeddi: No, none of them are. I never setup puppet on those servers, and I'm still learning what all their puppet setup does. :)
13:39 jeddi argh.
13:39 jeddi what i meant to say, Psi-Jack, is that that sounds like a delightful and easy project that will involve you being very happy for several weeks.
13:40 Psi-Jack LOL
13:40 jeddi guessing you're using hiera plugin on puppet?
13:40 Psi-Jack Well, I'm currently converting my home puppet setup, which yes, I did make all the pp's myself, into salt. Just so I know salt. :)
13:40 Psi-Jack jeddi: yep.
13:40 jeddi ack.
13:41 Psi-Jack pillars seems to be able to sort of be similar, but data is not cascaded down like hiera does.
13:41 jeddi in reality .. it'll be frustrating, but testing sanity of the yaml recipes will be relatively easy .. trying to automate the whole swathe in one fell swoop would be a nightmare.  hopefully they're divided up into several roles / categories.
13:41 Psi-Jack A pillar is all-or-nothing, and nothing else can replace another defined pillar state.
13:42 Psi-Jack jeddi: they are, on the ~200 servers, thankfully.
13:42 jeddi yeah.  if you read up on the pillar introduction from middle of last year (?) it was loosely modelled on hiera .. but obviously not a replica of the functionality.
13:42 Psi-Jack Grouped. :)
13:42 Psi-Jack I see. So I am at least on the right track.
13:42 jeddi i think there is talk of having pillars offer inheritance / superceding features.
13:43 txmoose So I just blew away /etc/salt on all 4 boxes and removed everything with yum.... installed it all again, went through setup and nothing still...
13:43 Psi-Jack If I want hierarchical data, I need to define that hierarchy in a code-like pillar state.
13:43 jeddi the ground you're treading is not entirely untrod .. but i'm guessing not terribly well documented.  i'd imaginea  few people have blogged about the same type of transition, though, if you can find 'em.
13:43 Psi-Jack Such as sampled: https://github.com/saltstack-formulas/ntp/blob/master/formula2/ntp/pillardata/ntp.sls
13:43 txmoose # salt '*' test.ping
13:43 txmoose shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
13:43 Psi-Jack jeddi: yeah. Seems googling for salt ends badly.
13:43 jeddi txmoose: the same tests - telneting to the salt ports - they still fail to return data?
13:44 jeddi Psi-Jack: use 'saltstack' to narrow it down - though many blog posts don't use that string, regrettably.
13:44 Psi-Jack yeah.
13:44 jeddi you can use "salt stack" (quoted) in google ..t hat sometimes helps, I've found.
13:44 Psi-Jack I've narrowed it down some just by adding the "linux" keyword in, but I still get results about salt (the white kind), and Salt Lake city.
13:44 Psi-Jack lol
13:44 txmoose jeddi: telnet'ing to the 2 ports connects on all 3 other servers.
13:44 jeddi txmoose: are you in /srv/salt?
13:45 jeddi the can't retrieve cwd usually means you've deleted the directory you're sitting in.
13:45 txmoose I have a /srv/ but it's empty
13:45 jeddi oh.  txmoose where is your salt states pointing to (in master configuration) - usually defaults to /srv/salt
13:46 txmoose I don't have any states yet I don't think.... let me look
13:46 jeddi though i guess cmd.run's will eb fine without any states files.
13:46 jeddi being beckoned - back later.
13:49 txmoose FWIW: I have no states yet, and /srv/ is empty... so I'm at a loss here for where it's getting information on this stuff...
13:50 jeddi txmoose: as i say, you wouldn't need states in order to do a cmd.run .. but i also wouldn't expect salt-master to fail to perform absent the states directory .. nonetheless it'd be good to rule that out - ie. by creating it, and putting in an empty top.sls for it.
13:50 jeddi anyway - back later.
13:50 txmoose thanks jeddi
13:57 bhosmer joined #salt
13:57 oliv_mc joined #salt
14:00 bhosmer joined #salt
14:01 txmoose OK, guys... all 4 are working now... I was trying to get them all to talk on the servicenet at my datacenter... apparently that servicenet doesn't like that... not sure why, but it wasn't working right.
14:01 txmoose So I'll dig more into that later on.
14:01 txmoose But once I switched em all to the public interface, they work fine.
14:02 txmoose I have to find out why our servicenet was being crappy about it.
14:02 Teknix joined #salt
14:06 luminous https://github.com/madduck/reclass << this is a little bit like a holy fsck.. haven't yet played with it, but looks freekin awesome
14:06 bhosmer joined #salt
14:08 LyndsySimon joined #salt
14:09 xinkeT joined #salt
14:19 txmoose jeddi: as a follow up to earlier, once I accepted all the keys across public network, I changed things back to private network 1 by 1 and they all work like nothing's wrong now....
14:20 txmoose Beyond that, you CAN point a minion at 127.0.0.1
14:20 txmoose AND you can point it at 'localhost'
14:26 carmony joined #salt
14:41 jessep joined #salt
14:54 kenbolton joined #salt
15:03 rglauser joined #salt
15:07 kenbolton joined #salt
15:12 opapo joined #salt
15:13 jeddi txmoose: cool - i thought they should be fine to talk to localhos .. but it's weird that they needed to auth via a the public i/face.
15:15 p3rror joined #salt
15:16 jkleckner joined #salt
15:27 auser joined #salt
15:28 txmoose jeddi: I have no idea why it was acting that way...
15:28 txmoose Anyway, I have 5 minions talking to it now.  4 CentOS and 1 OpenSUSE.  I'm curious, though, as to why the minion version on my openSUSE system is 0.15.90
15:29 txmoose My CentOS versions report 0.15.3
15:33 txmoose Also, the openSUSE minion doesn't handle dicts like CentOS does
15:36 auser joined #salt
15:41 kenbolton joined #salt
15:43 ronc joined #salt
15:44 jeddi txmoose: did you bootstrap the opensuse box?  that generally defaults to booting latest from git i believe, which would explain .90 (rc for 0.16)
15:45 jeddi txmoose: just make sure you've got libzmq3 (if it's available) on each box.
15:48 dthom91 joined #salt
15:49 tomeff_ joined #salt
15:52 txmoose jeddi: I added the repo to zypper that's recommended on the openSUSE official install guide
15:53 txmoose Truth be told, I'm still learning openSUSE so I'm not quite sure how zypper works yet.
15:54 jeddi i last used suse in 2007.  i still occasionally wake up screaming in the middle of the night because of that experience.
15:55 txmoose lol it's got a pretty slick interface now that they're using KDE 4.10.  It was recommended to a friend of mine who wanted to change from windows to linux because their ideaology is "let's make sure we can do everything in a GUI"
15:56 txmoose But I digress.  I'm poking around now.  Isn't there a way to tell sls files "vim is actually vim-enhanced on CentOS systems"?
15:58 jeddi kde 4.10 is in experiemntal on debian i think.  prolly should upgrade i guess.     and yes - you set up a pillar that defines what package you mean by 'vim' baesd on the grain for distro (from memory) and then install that package in the state file.
15:58 jeddi it's one of the first examples .. hang on ..
15:59 jaequery joined #salt
16:00 jeddi txmoose: https://salt.readthedocs.org/en/latest/topics/tutorials/pillar.html
16:00 jeddi under 'parameterizing states with pillar'
16:02 Psi-Jack parameterizing? Ooooh
16:03 Psi-Jack Oh... That...
16:03 jeddi not an issue for people with homogenous networks :)
16:03 Psi-Jack Though, pillar.get may be huseful to me.
16:03 jeddi very much so.  read up on pillar.get versus pillar[] ... i don't recall the details but there were some potential gotchas on using each.
16:04 Psi-Jack I wonder.... If you could do something like, say... ntpservers: {{ salt['pillar'get']('ntp-server:ntpservers
16:04 Psi-Jack Blah, sec..
16:04 bhosmer joined #salt
16:05 jeddi Psi-Jack: https://github.com/saltstack-formulas/ntp/tree/master/formula2/ntp
16:05 Psi-Jack ntpservers: {{ salt['pillar'get']('ntp-server:ntpservers', 'ntp:ntp-servers') }} or ntpservers: {{ salt['pillar'get']('ntp-server:ntpservers', {{ pillar['ntp']['ntp-servers'] }}) }}
16:05 Psi-Jack jeddi: Yeah, I know, I've pointed that one out a few times, and it's kinda a PITA. :)
16:06 oz_akan_ joined #salt
16:06 Psi-Jack When I think "parameterizing", I'm thinking passing parameters into something, not making conditional clauses within the routine.
16:06 jeddi Psi-Jack: i thought someone had mentioned that a while ago .. it's one of my chromium tabs of 'stuff to read' :)
16:06 Psi-Jack hah
16:07 Psi-Jack jeddi: yep. My current ntp basis is on that now, with some adjustments in conditions, but the concept is a bit... Bleh.. IMHO. :)
16:07 Psi-Jack I'm hoping to find a better way than that.
16:07 jeddi ah, yeah, that's what i'm digging into at the moment.   passing users, db servers, db, db.tables, and specific rights (select, delete, etc)via pillar.
16:07 txmoose jeddi: thanks man.  Yea, I'd like to have all my boxes be CentOS, but I was asked to help keep this box going while they learn linux
16:08 txmoose So if I can do it all via a central location, I'll be much more apt to do it.
16:08 jeddi txmoose: hey, no worries.  i fully appreciate there's often good reasons to maintain a heterogenous network .. it's jsut a few more challengs, that's all.
16:08 Psi-Jack heh, I used to hate CentOS. CentOS 5.x anyway. 6.x has turned out to be quite acceptable though. :)
16:09 Psi-Jack I currently, at home, run a bit of a mixture myself. Currently (though changing when I can), Arch Linux based Ceph servers x3, Debian 6 servers x4 running Proxmox VE 2.3, and have been converting my Debian, Ubuntu, and Arch-based VM's to CentOS 6.4
16:09 txmoose I like 6.  5 I don't have much experience with.  I got my RHCSA on RHEL 6, so I'm kind of obliged to like CentOS/RHEL 6 :P
16:10 djn joined #salt
16:10 auser joined #salt
16:10 Psi-Jack txmoose: Last company I worked for only had 4 CentOS 5.x VMs. Everything else was Ubuntu 10.04. Current company is rocking with all CentOS 6.x
16:10 txmoose Arch is on my local machines (except the gaming rig.... but that's a "no work zone" so I only keep linux VMs on it)
16:11 txmoose Psi-Jack: We're a hosting provider.  I think about 60% of our customers are on ubuntu... and I hate them for it :P
16:11 jeddi tehre's many reasons to dislike ubuntu.  but few to prefer rhel/centos/suse.  ;)
16:11 Psi-Jack txmoose: last company was a hosting services company, but hosting a SaaS product, not VPS or such.
16:13 txmoose I'm on the VPS side of the house.  Thankfully, I get to work with the managed customers, so I don't often have to babysit people through "type xyz to do this... ok now type what I told you to type so it works"
16:13 Psi-Jack heh
16:14 Psi-Jack Yeaaah. I'm back in th eproper industry where I'm not dealing with external customers at all. :)
16:14 Psi-Jack Just babysitting the in-house servers running our product. :)
16:15 txmoose Hahaha it's not all bad.  The managed customers know that they don't know what they're doing.  So they're pretty cool
16:17 jbunting joined #salt
16:17 oz_akan_ joined #salt
16:23 bhosmer joined #salt
16:25 txmoose Well, gentlemen, I work the night shift, so I've been working all night.  It's my bed time. Thank you for the help.  I really appreciate it.  I'm sure I'll be back in with stupid questions later on. Have a great day, guys.
16:26 jaequery joined #salt
16:29 bhosmer_ joined #salt
16:32 carmony joined #salt
16:33 bhosmer joined #salt
16:44 bhosmer joined #salt
16:48 rfgarcia joined #salt
16:50 madduck luminous: that's nice of you to say.
17:10 LyndsySimon_ joined #salt
17:16 Jarus joined #salt
17:20 ronc joined #salt
17:24 mike007 joined #salt
17:29 kleinishere joined #salt
17:37 mike007 left #salt
17:40 faust joined #salt
17:44 Gifflen joined #salt
17:44 nrub joined #salt
17:51 kenbolton joined #salt
17:53 mgw joined #salt
17:57 rfgarcia joined #salt
18:01 rfgarcia joined #salt
18:03 steamraven_ joined #salt
18:05 Nexpro1 joined #salt
18:06 whit joined #salt
18:33 jayd3e joined #salt
18:34 jbunting joined #salt
18:39 raydeo joined #salt
18:48 LyndsySimon joined #salt
18:53 carmony joined #salt
18:57 berto- joined #salt
18:59 alazylearner joined #salt
19:13 HaxCore joined #salt
19:19 Dieterbe left #salt
19:20 raydeo joined #salt
19:33 LyndsySimon joined #salt
19:41 jayd3e so pillars are pretty much a set of global data accessible to the sls files?  Data that is specific to minions most of the time?  So for example, let's say I need to use a different user for my dev machine than my prod machine, a pillar is a good use case for such a scenario?
19:50 p3rror joined #salt
19:52 kstaken joined #salt
20:00 p3rror joined #salt
20:05 jeddi joined #salt
20:05 luminous madduck: hrm?
20:05 luminous jayd3e: you arfe more or less 100% correct
20:06 jayd3e luminous: kk cool thanks
20:06 luminous data in pillar is only available to those minions you specify via top.sls
20:07 luminous but in general, it's the best place for 'the details', regardless of whether you care or not that it is llimited to that node
20:07 luminous in other words, put everything from sensitive data to the names of packages and services
20:07 luminous then refer to them in both templated sls and configs
20:08 luminous in this way, your stuff will be super portable
20:09 jayd3e kk awesome, that works great
20:18 lemao joined #salt
20:28 [ilin] joined #salt
20:42 mgw joined #salt
20:55 alazylearner joined #salt
20:58 JordanRinke Morning
21:06 LyndsySimon joined #salt
21:14 sciyoshi2 joined #salt
21:14 ronc joined #salt
21:16 bhosmer joined #salt
21:31 copelco joined #salt
21:31 copelco does anyone have a salt state for installing solr?
21:35 bemehow joined #salt
21:42 Psi-Jack Besides trying to actually push a state out to the network, is there a way to just locally, on the salt-master, do a check on the highstate's compiling ability on a node, acting like it would, but doesn't actually do so?
21:44 Psi-Jack I ask mainly because I'm about to push a highstate over to a node that's never been on the salt network, yet, and is a different os_family than the others, and I just adjusted my states for that differentiation, specifically for the LDAP authentication stuff.
21:44 madduck luminous: re:reclass.
21:45 jkleckner1 joined #salt
21:46 madduck Psi-Jack: I think that would be impossible, at least not 100% error-free. Don
21:46 madduck Argh
21:46 madduck Don't push to a node that is doing work for you without testing
21:46 madduck Can you clone the node to a local VM and try the result?
21:46 madduck Anyway, I need to go to be.
21:46 madduck Oh screw this keyboard.
21:47 madduck bed. that is where I need to go to.
21:47 Psi-Jack heh
21:47 Psi-Jack And.. Yes, I could, would only add about an hour for everything. :p
21:48 Psi-Jack So far, it's mostly okay, though. I already pushed it to high state, found some errors, but nothing unmanagable.
21:54 Psi-Jack Holy crap, and it works! :d
21:55 Psi-Jack So, now, I at least got CentOS and Debian/Ubuntu mix supported in my states pretty well so far. This'll just help me enforce keeping that logic as needed.
22:02 p3rror joined #salt
22:02 isomorphic joined #salt
22:05 fllr joined #salt
22:06 fllr I'm using salty vagrant to create a dev environment. but when I run salt-call --local state.highstate I get this error: Failed to create directory path "/etc/salt/pki/minion" - [Errno 13] Permission denied: '/etc/salt/pki/minion'. What's going on?
22:09 bluemoon joined #salt
22:11 oz_akan_ joined #salt
22:15 Psi-Jack Does salt, itself, ever poll/push state.highstate on its own, or is that something, if I want to happen, have to setup as a cron job or something?
22:15 luminous fllr: sounds like you are not running salt as root
22:15 rglauser joined #salt
22:19 kstaken joined #salt
22:22 mackstick Psi-Jack: http://docs.saltstack.com/topics/tutorials/cron.html - this would suggest that yes, you need to use a cron job
22:25 luminous Psi-Jack: it does not do anything itself, unless you tell it to
22:25 luminous but, thankfully, it's pretty easy to do so
22:25 Psi-Jack Gotcha. :)
22:25 jkleckner joined #salt
22:26 Psi-Jack So, either the minions can to state-call, or the master can do state '*'. Seems reasonable.
22:28 luminous yep
22:28 luminous it all depends on what you want to do
22:28 luminous some folk prefer to run that themselves
22:29 luminous or even run specific states/modules individually
22:31 * Psi-Jack nods.
22:33 Psi-Jack Hmm, with that in mind, I have one more immediate question. state.highstate basically does everything, but is there a way to make a state that doesn't get into the highstate, but could push out manually otherwise?
22:33 Psi-Jack or would that be just.. Not putting the state into the top.sls, and just keeping it independently?
22:38 jeddi Psi-Jack:  you can push a state, yes.
22:39 jeddi Psi-Jack:  you know about test=True do you?  (just reading back)
22:39 dlawler_ joined #salt
22:39 jpcw_ joined #salt
22:41 kleinishere joined #salt
22:41 Psi-Jack jeddi: Hmm, no, I don't?
22:43 rsimpkins How do I approach this one? I wanna wrangle my iptables files. They are big. About 25% of the file is shared among all hosts. 75% is unique, though some of the components are shared with a few hosts. The sections are 20-30 lines each, whith a total file about 500-600 lines. Ideas how I can templatize this beast?
22:44 Psi-Jack heh
22:44 dahunter3 joined #salt
22:44 Psi-Jack rsimpkins: Shorewall, and saltstack those files. :)
22:45 rsimpkins I can look at shorewall to see if will help. But yeah - the idea is to use salt to wrangle this thing.
22:46 rsimpkins Templates are great when a few things need to change per hosts. But 75% changing per host - and I'm about ready to just copy the stupid thing N times.
22:46 Psi-Jack Shorewall uses templates to define the firewall structure, basically.
22:46 Psi-Jack And they get compiled into iptables rules.
22:50 jeddi joined #salt
22:58 rsimpkins I think I'll plan a migration to shorewall at a later date. Based on my config - that'd be a huge project right now. Worth doing, just not for right now.
22:59 rsimpkins In the mean time, can I include files with jinja?
22:59 rsimpkins I could break things out in to various sub files at least.
22:59 rsimpkins The docs say I can include, but I don't know how the 'path' is interpreted.
22:59 rsimpkins relative to salt's path, or the file destination path.
23:02 ThomasB joined #salt
23:02 ThomasB left #salt
23:15 z3uS joined #salt
23:20 bluemoon joined #salt
23:23 jeddi joined #salt
23:36 robbyt joined #salt
23:40 jeddi joined #salt
23:52 oz_akan_ joined #salt
23:53 jeddi Anyone seen some good examples of defining users in pillar AND being able to select specific users, perhaps by a group, perhaps arbitrarily, in a state to deploy to a particular host (or group of hosts).
23:59 Xeago joined #salt

| Channels | #salt index | Today | | Search | Google Search | Plain-Text | summary