Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2014-11-07

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

All times shown according to UTC.

Time Nick Message
00:02 otter768 joined #salt
00:03 rihannon I'm trying to write my own ext_pillar.  I'm getting the error: Specified ext_pillar interface networklist is unavailable
00:04 rihannon As best as I can tell, this is because salt.loader.pillar is failing to load my networklist.py module, but I don't understand why.
00:04 glyf joined #salt
00:05 rihannon It executes the module because both of my stub functions for __init__() and __virtual__() get called.
00:05 pipps joined #salt
00:06 Ryan_Lane joined #salt
00:06 teebes joined #salt
00:08 meylor joined #salt
00:09 Ryan_Lane when will 2014.7 packages make it to EPEL?
00:10 smcquay joined #salt
00:18 aranhoide joined #salt
00:20 aranhoide salt-cloud question: http://docs.saltstack.com/en/latest/topics/cloud/azure.html doesn't clarify whether you can use the .pem file to log into newly created azure minions, or whether you need to do it by SSH password
00:21 aranhoide in azure's web interface you can provide a .cer and you can then log into that machine with `ssh -i azure.pem azureuser@mymachine.cloudapp.net`
00:23 aranhoide can Salt do something similar, or is the .pem you configure in the cloud.providers entry *only* for authentication into the azure API itself?
00:24 aranhoide in Salt you can configure SSH keys for, say, Digital Ocean and EC2
00:24 aranhoide I mean, for the minions created in those providers
00:28 bhosmer joined #salt
00:29 StDiluted joined #salt
00:33 srage joined #salt
00:33 notpeter_ aranhoide: You can certainly configure authorized_keys for users on the newly provisioned machines to include your preferred public keys
00:33 nyx_ joined #salt
00:34 notpeter_ But I think that certificate_path is only used for the management of those instances with the azure API.
00:35 notpeter_ But you can configure per-minion public keys in authorized_keys applied with a normal state.
00:36 Outlander joined #salt
00:37 aranhoide thanks notpeter_ !  I was thinking of how to make it so Salt itself uses ssh keys to provision that machine on launch.  but yeah, I guess I can disable password logins in the salt config
00:38 notpeter_ Yeah, that's what we do. The first state it runs applies an sshd_config, just make sure have it also reload the sshd service by adding a watch clause to the ssh service.
00:41 cads joined #salt
00:44 n8n joined #salt
00:45 Ahrotahntee can anyone explain to me the difference in the output between "salt '*' cmd.run "pwd"" in my minions? > http://www.flying-dragon.ca/paste/0a23d81b52b09354
00:52 badon joined #salt
00:52 b1nar1_ joined #salt
00:53 iggy did you start one of the minions by hand from the command line (vs starting it via the init script or it being started on boot?)
00:53 aranhoide thanks again, notpeter_, I'll make sure to do that!
00:56 bhosmer joined #salt
00:57 CeBe joined #salt
00:58 forze joined #salt
01:01 aqua^mac joined #salt
01:03 pacopablo joined #salt
01:09 b1nar1 joined #salt
01:11 pipps joined #salt
01:15 zlhgo_ joined #salt
01:18 MrFuzz joined #salt
01:21 Ahrotahntee iggy: they all ought to have been started by system at boot
01:21 Ahrotahntee iggy: I installed the salt-minion package and created a stock image that I spin all my VMs up form
01:21 Ahrotahntee s/form/from/
01:22 Ahrotahntee so they're identical in every way except for host keys and the fqdn
01:22 ajolo joined #salt
01:22 Ahrotahntee but, with that vein of thought I will restart the services
01:23 Ahrotahntee and they are all now running under /root
01:23 Ahrotahntee iggy: good call. thanks :)
01:24 seydu joined #salt
01:28 elfixit joined #salt
01:31 mapu joined #salt
01:35 mapu joined #salt
01:35 zlhgo__ joined #salt
01:36 n8n joined #salt
01:39 n8n joined #salt
01:39 mapu joined #salt
01:40 clone1018_ joined #salt
01:44 ajolo joined #salt
01:48 druonysuse joined #salt
01:56 snuffeluffegus joined #salt
01:56 mapu joined #salt
01:58 TheThing joined #salt
01:58 jalaziz joined #salt
02:02 TheThing joined #salt
02:03 mapu joined #salt
02:05 bezeee joined #salt
02:07 mapu joined #salt
02:11 mapu joined #salt
02:14 mapu joined #salt
02:15 aparsons joined #salt
02:22 nitti joined #salt
02:28 kusams joined #salt
02:33 Nazca joined #salt
02:34 linjan joined #salt
02:36 n8n joined #salt
02:39 pipps joined #salt
02:45 racooper joined #salt
02:45 bhosmer joined #salt
02:46 bhosmer_ joined #salt
02:58 aranhoide joined #salt
02:59 perfectsine joined #salt
03:07 n8n joined #salt
03:11 Mso150 joined #salt
03:11 possibilities joined #salt
03:17 linjan joined #salt
03:22 n8n joined #salt
03:25 mapu joined #salt
03:28 mapu joined #salt
03:30 cberndt joined #salt
03:35 mapu joined #salt
03:45 jalaziz joined #salt
03:46 iggy i do what i can
03:47 stooj hi. Setting up a server with salt-cloud and I get a few of these errors during the build. https://www.refheap.com/92843
03:47 stooj I feel sure this is a solved problem, but I'm not sure how to fix it
03:54 ajolo joined #salt
03:54 n8n joined #salt
03:57 tmh1999 joined #salt
03:57 zekoZeko_ joined #salt
03:59 tmh1999 joined #salt
04:00 viq joined #salt
04:01 iggy stooj: using salt-bootstrap.sh
04:01 iggy ?
04:03 tmh1999 joined #salt
04:03 stooj iggy: I think so - I'm not making a choice to use it, it's just what's getting used.
04:03 stooj I set up the cloud-providers.d config and the cloud-profiles.d config
04:04 stooj I think that's about it
04:04 iggy so... start from the beginning
04:04 iggy ohhhh
04:04 iggy using salt-cloud to set up a server
04:05 iggy not setting salt-cloud on a server
04:05 stooj Yep
04:05 stooj Sorry, wasn't clear
04:13 iggy stooj: what version of salt-cloud?
04:13 stooj salt-cloud 2014.1.13 (Hydrogen)
04:14 iggy salt-cloud -u
04:14 iggy then try again
04:16 stooj OK
04:16 n8n joined #salt
04:17 beneggett joined #salt
04:17 iggy oddly, it doesn't look like that's actually failing
04:17 iggy (upon second look)
04:27 stooj It's not bombing out - is it not leaving packages unconfigured though?
04:28 dooshtuRabbit joined #salt
04:29 JlRd joined #salt
04:29 stooj The full paste, minus apt-update noise: https://www.refheap.com/92844
04:30 iggy if it completes, you can probably just do an apt-get -f install or dpkg-reconfigure whatever package
04:30 jcristau joined #salt
04:32 stooj iggy: which means reading through the log, figuring out what has failed and manually fixing it. I was kinda hoping that there would be some mechanism for automating all of that :(
04:33 bhosmer joined #salt
04:34 iggy honestly, I wouldn't worry about it
04:35 iggy if everything is working okay, just roll with it
04:35 iggy I can't imagine what "debian-archive-keyring" could need preconfigured
04:37 stooj OK, thanks iggy :) I think most of my worries come from not being sure if I'm using salt right or not.
04:38 __gotcha joined #salt
04:42 druonysus joined #salt
04:42 druonysus joined #salt
04:51 joehh ecdhe:
04:52 joehh I believe the -d is not needed as under systemd, the systemd init looks after daemonising
04:53 iggy stooj: don't worry about that yet... just keep chugging through, you'll piece it all together later
04:54 stooj Heh - thanks
05:10 linjan joined #salt
05:11 ecdhe thanks joehh!
05:12 meylor joined #salt
05:18 Furao joined #salt
05:28 capricorn_1 joined #salt
05:29 Katafalkas joined #salt
05:33 badon joined #salt
05:35 Reiner034 joined #salt
05:47 glyf joined #salt
05:51 ramteid joined #salt
05:56 linjan joined #salt
06:07 pdayton1 joined #salt
06:11 MrFuzz joined #salt
06:13 meylor joined #salt
06:15 NightMonkey joined #salt
06:22 bhosmer joined #salt
06:35 catpiggest joined #salt
06:39 nyx_ joined #salt
06:40 badon joined #salt
06:46 Nexpro joined #salt
06:53 linjan joined #salt
06:54 n8n joined #salt
06:56 SpX joined #salt
06:57 calvinh joined #salt
07:08 ndrei joined #salt
07:09 kusams joined #salt
07:10 ProT-0-TypE joined #salt
07:18 flyboy joined #salt
07:28 feth joined #salt
07:30 trikke joined #salt
07:31 bahadir joined #salt
07:38 TyrfingMjolnir joined #salt
07:51 b1nar1_ joined #salt
07:57 lothiraldan joined #salt
08:07 lcavassa joined #salt
08:07 eseyman joined #salt
08:11 bhosmer joined #salt
08:19 ramishra joined #salt
08:21 karimb joined #salt
08:22 baconbeckons joined #salt
08:34 CeBe joined #salt
08:35 Mso150 joined #salt
08:35 PI-Lloyd joined #salt
08:41 __gotcha joined #salt
08:42 martoss joined #salt
08:49 intellix joined #salt
08:56 JlRd joined #salt
09:00 jhauser joined #salt
09:09 oyvjel joined #salt
09:09 hawcktut joined #salt
09:13 hawcktut hi gius
09:13 hawcktut *guys
09:13 JlRd joined #salt
09:14 hawcktut i am trying to check a yaml list which is nested in a dictionary and then compare the values if they match to a certain string
09:14 hawcktut for example:
09:14 hawcktut https://justpaste.it/saved/7931382/b2cb11fa
09:15 JlRd joined #salt
09:15 hawcktut http://justpaste.it/hvnf
09:15 hawcktut but its not workig
09:15 hawcktut anyone can give me some help on that?
09:21 jdmf joined #salt
09:22 N-Mi_ joined #salt
09:22 N-Mi_ joined #salt
09:27 linjan joined #salt
09:27 gerardjp joined #salt
09:28 gerardjp Anybody a clue if this nested pillar querywill become a performance hit: {{ pillar['servers'][   pillar['sites'][ fqdn ]['node']  ]['primary_ip'] }} (the site attrib node is used to inquire the servers Ip)
09:33 gerardjp nevermind .. there's something called grains ;)
09:36 ramteid joined #salt
09:37 lothiraldan joined #salt
09:42 alexr_ joined #salt
09:46 badon_ joined #salt
09:57 peno joined #salt
10:00 bhosmer joined #salt
10:04 Reiner034 joined #salt
10:05 timbermaniac joined #salt
10:13 CeBe joined #salt
10:13 Reiner034 joined #salt
10:17 Reiner035 joined #salt
10:38 diegows joined #salt
10:38 badon joined #salt
10:41 jhauser joined #salt
10:43 baconbeckons joined #salt
10:47 baconbeckons joined #salt
10:52 __gotcha1 joined #salt
10:57 akafred joined #salt
10:58 hawcktut anyone can link some examples  how to manipulata yaml lists
10:58 hawcktut for loops in lists values (not dictionaries)
11:01 calvinh_ joined #salt
11:06 NV joined #salt
11:14 TyrfingMjolnir joined #salt
11:14 ProT-O-TypE joined #salt
11:18 AmrMostafa joined #salt
11:19 AmrMostafa Is this a valid glob match? '*foo* and *bar*'
11:19 AmrMostafa or should that use an 'or' ?
11:23 rattmuff hawcktut: not sure if this might help you: https://github.com/saltstack-formulas/users-formula
11:24 giantlock joined #salt
11:24 rattmuff AmrMostafa: not sure what you are trying to do, perhaps ['*foo*', '*bar*'] ?
11:25 rattmuff AmrMostafa: can't help you much with globbing but I think this is a nice reference for my use at least: http://docs.saltstack.com/en/latest/topics/targeting/globbing.html
11:27 AmrMostafa rattmuff: thanks, but I couldn't find any where in the docs a section that explains the 'and' , 'or' with globbing
11:27 viq AmrMostafa: compount
11:27 viq compound, it would help if I could spell
11:27 viq AmrMostafa: http://docs.saltstack.com/en/latest/topics/targeting/compound.html
11:28 AmrMostafa viq: if you check that out, it doesn't directly explain that you can use 'and' and 'or'
11:29 AmrMostafa viq: just uses them in examples demonstrating Regex and other advanced methods
11:29 AmrMostafa seems that they work fine with globs though, I was just using 'and' where I should have used 'or'
11:29 calvinh joined #salt
11:30 viq hm
11:32 fejese hi! is there a way to return the changes for a cmd.run state as the changed flag can be returned when using stateful=true?
11:36 dvestal joined #salt
11:37 fredvd joined #salt
11:38 Katafalk_ joined #salt
11:41 spo0nman joined #salt
11:44 agend joined #salt
11:48 bhosmer joined #salt
11:51 bhosmer_ joined #salt
11:53 linjan joined #salt
11:54 alexr_ joined #salt
11:54 bhosmer joined #salt
11:54 spo0nman are there a way for a salt-minion to execute a salt command?
11:54 spo0nman i run command on minion -> take output pass to another salt command
11:56 diegows joined #salt
11:59 aqua^mac joined #salt
12:00 giantlock joined #salt
12:00 aqua^mac joined #salt
12:01 rancor joined #salt
12:04 alexr_ joined #salt
12:06 alexr__ joined #salt
12:06 AmrMostafa spo0nman: `salt-call` is used to execute salt module functions locally on a minion
12:07 spo0nman i'd like to execute a command on the salt master
12:08 spo0nman based on output of a salt cmd.run on a minion
12:09 viq spo0nman: I believe you want the reactor system
12:10 spo0nman viq yeah! i was looking into it. but it looks like i need to do something with states
12:10 Katafalkas joined #salt
12:10 viq hm?
12:10 viq what do you mean, "do something with states" ?
12:11 viq hm, http://docs.saltstack.com/en/latest/ref/states/all/salt.states.event.html
12:11 viq looks like it should be pretty easy to do with 2014.7
12:12 spo0nman viq: i want to run scritpx on host[1-10] if output of  script y on host6 is blah.
12:13 viq spo0nman: yes, you generate an event on host6 if something, and program a reactor to run scriptx on host[1-10]
12:13 spo0nman viq ah! super
12:13 viq you can generate events from scripts too, AFAIK, though it may require a bit of python
12:13 spo0nman viq let me give it a shot
12:14 viq You do that, and I go get lunch :P
12:14 spo0nman viq: thanks :)
12:16 imanc if I try to include a single state file from a package, e.g. include:  mypackage.mystate    I get an error saying that the state can't be found.  Is this possible?
12:18 rattmuff imanc: are you sure you have the correct path and that the state you try to include compiles correctly?
12:18 babilen imanc: No, you can only include entire SLS files
12:18 kusams joined #salt
12:18 imanc just to clarify ,this is a directory that has an init.sls and mystatefile.sls .. and i only want to include mystatefile.sls
12:19 babilen imanc: The use "include: - yourdirectory.mystatefile"
12:19 imanc rattmuff: the path seems correct, as does the state. Is it possible to get more detailed error information from salt?
12:19 rattmuff imanc: perhaps you mean to include mypackage.mystat.mystatefile
12:19 babilen imanc: You have to be more precise if you want actual help. Feel free to paste your directory/file structure, their content and the error you get.
12:19 babilen (to, say, http://refheap.com )
12:20 linjan joined #salt
12:20 imanc babilen: OK, thanks. I'll grab some sls :)
12:21 rancor Hi, got a strange issue. state.sls <some random state> works perfect for a host but state.highstate don't returns anything and if I'm looking in the log for salt-minion this message are looping: [salt.minion      ][TRACE   ] Check main poller timeout 1
12:22 babilen rancor: Does your highstate include additional states apart from <some random state> ? And if so: Does each state work individually?
12:22 bhosmer joined #salt
12:22 babilen SLS
12:22 rancor babilen: I think I have tested every single state. Is there a way to compile a list of states that will be used.. if I'm missing something
12:22 rancor I will try again
12:23 oyvjel joined #salt
12:24 babilen Debug logs might help, but I'm off for lunch now. All the best!
12:28 martoss left #salt
12:30 hobakill joined #salt
12:30 kusams joined #salt
12:31 __gotcha joined #salt
12:32 blaffoy joined #salt
12:35 ProT-0-TypE joined #salt
12:35 nyx_ joined #salt
12:36 blaffoy Hi, I'm having some trouble with file.managed on a Windows 7 minion.
12:36 hobakill i just threw up in my mouth a little.... i tried to upgrade the 'curl' package using: salt -G "kernel:Linux" pkg.upgrade curl  --- and all my linux minions upgraded every package they had available. i'm not sure why that happened.
12:38 hobakill ah - i know why... beause i'm a f'ing idiot
12:38 babilen hobakill: pkg.upgrade is the equivalant of "apt-get upgrade" -- it is not possible to upgrade a single package like that. You would use "pkg.install" for that.
12:38 blaffoy sls looks like this:  C:\windows\SysWOW64\config\systemprofile\.pythonrc.py:   file.managed:     - source: salt://python/systemprofile-pythonrc.py     - template: jinja
12:38 hobakill babilen: yep. i read the dox wrong. goddamn it.
12:38 babilen (or "apt-get install PKG") -- in 2007.7 you can restrict that to only "install" (i.e. upgrade) already installed packages
12:39 babilen Well, at least your minions are now up-to-date. You were planning to do that anyway, weren't you?
12:39 blaffoy But on state.highstate I get "Name: C:\windows\SysWOW64\config\systemprofile\.pythonrc.py - Function: file.managed - Result: Failed"
12:39 calvinh joined #salt
12:39 hobakill babilen: of course! but i guess i would have done it in a less nuclear manner. or...y'know... test=True... :/
12:39 blaffoy However, I can used cp.get_file to copy the file, and it works fine.
12:40 blaffoy Any ideas what the problem is?
12:40 blaffoy salt version 2014.1.11
12:40 JlRd joined #salt
12:41 babilen hobakill: Sorry, I did not meant to joke about it as things like this can be absolutely horrible (omg, did I really just do that on every single fucking machine I have?!?!?), but at least it was an "upgrade" and not a purge or removal or whatnot
12:41 calvinh_ joined #salt
12:43 hobakill babilen: hey man no worries! i didn't take it as a joke at all. i think i dodged a bullet for the most part... we'll see what happens when the devs get in this morning.... :)
12:43 babilen "Guys! Rejoice! Everything works on the newest version!"
12:43 babilen it just shows how careful one has to be with salt ...
12:44 hobakill well - shinken/nagios hasn't gone berserk so i think i'm ok.....
12:44 babilen *phew*
12:44 hobakill thanks babilen! :)
12:45 calvinh_ joined #salt
12:45 babilen There isn't really a way to upgrade single packages on Debian. An "apt-get install PKG" will always change the "automatically installed" bit so you would have to check the status first with apt-mark and revert if it was, in fact, automatically installed.
12:47 calvinh joined #salt
12:52 hobakill left #salt
12:53 blaffoy Okay, I can I can use file.managed to put a file into another directory, so I'm guessing it's a permissions issue.
12:53 hobakill joined #salt
12:56 diegows joined #salt
12:57 karimb joined #salt
13:01 blaffoy Okay, I see the problem. The managed file is a jinja template. The pillar does not have a necessary value set to complete the jinja step.
13:01 jaimed joined #salt
13:06 blaffoy Yep, that was it.
13:06 blaffoy Thanks
13:15 mgw joined #salt
13:15 intellix joined #salt
13:16 rancor babilen: I have now tried every single state manually and they work but when I run state.highstate nothing is returned
13:17 tristianc joined #salt
13:17 babilen rancor: Interesting, could you run the master in debug mode (or enable debug logging) and paste logs to http://paste.debian.net ?
13:17 rancor babilen: sure =)
13:19 oyvjel1 joined #salt
13:19 bhosmer joined #salt
13:22 rancor babilen: the simple answer on the master is that the minion don
13:22 rancor ops..
13:22 rancor dont answer before timeout
13:23 rancor maybe the amount of states data is to large for one "batch" ...   and the minion don't have enought power to respond before timeout
13:24 Katafalkas joined #salt
13:24 CeBe joined #salt
13:27 Furao joined #salt
13:27 aquinas joined #salt
13:30 elfixit joined #salt
13:30 babilen rancor: So you simply run into the timeout, but the highstate does, in fact, complete? Could you run it as "salt -v 'some_minion' state.highstate" and then check "salt-run jobs.lookup_jid $JIDFROMPREVIOUSCOMMAND"
13:31 rancor yes, it completes
13:31 rancor got this message: 2014-11-07 14:29:08,118 [salt.loader      ][TRACE   ] loading returner in ['/var/cache/salt/minion/extmods/returners', '/usr/lib/python2.7/dist-packages/salt/returners']
13:31 rancor 2014-11-07 14:29:08,118 [salt.loader      ][TRACE   ] Skipping /var/cache/salt/minion/extmods/returners, it is not a directory
13:31 rancor on the minion...
13:32 babilen so, no problem at all?
13:33 rancor except that nothing is reported back..  running latest salt, latest zmq on Ubuntu 14.04
13:33 rancor latest stable
13:33 babilen Waht about jobs.lookup_jid ?
13:33 rancor looking
13:34 rancor Yes, the result back
13:35 rancor salt-master does get the response back, but not fast enough?
13:36 dooshtuRabbit joined #salt
13:38 AmrMostafa joined #salt
13:38 ndrei joined #salt
13:39 rancor babilen: The same thing are happening every time. The jobs completes on the minion but the master does not get the result back in time. I can always find the result back later if I check with salt-run jobs.lookup.....
13:39 bernieke joined #salt
13:40 babilen rancor: So increase the timeout (-t 120) -- Does that also happen if you run the job in verbose mode (-v) as I suggested earlier?
13:42 bhosmer_ joined #salt
13:46 dvestal joined #salt
13:50 perfectsine joined #salt
13:51 teebes joined #salt
13:54 rancor babilen: yeah, -t120 did the trick..    What kind of timeout is this exactly? If we are running states with a couple of hundreds of actions, this one is just 152. Should we need to increase the timeout because of the "runtime" are getting longer?
13:56 babilen 120 seconds
13:56 babilen yeah, that is exactly what happens
13:56 dvestal joined #salt
13:57 rancor Ok, so this is the timeout for the response to get back, not if the minion are connected and working
14:01 babilen rancor: it is simply the timeout of the command line interface
14:02 babilen The jobs does complete, doesn't it? It is just that the interface doesn't wait as long as it takes for the minion to return.
14:02 cpowell joined #salt
14:03 cpowell joined #salt
14:03 babilen You can watch the event bus if you like to by using the eventlisten.py script (cf. http://docs.saltstack.com/en/latest/topics/reactor/#knowing-what-event-is-being-fired )
14:04 babilen You probably want to grab the eventlisten.py script from the salt version you use (e.g. from the 2014.1 or 2014.7 branch -- https://github.com/saltstack/salt/blob/2014.1/tests/eventlisten.py for example)
14:05 X86BSD joined #salt
14:05 bhosmer joined #salt
14:07 nitti joined #salt
14:07 kusams joined #salt
14:10 scott_w joined #salt
14:10 gngsk joined #salt
14:10 peters-tx joined #salt
14:11 kusams joined #salt
14:12 glyf joined #salt
14:13 nyx_ joined #salt
14:14 jstrom I got a few states which does cmd.run, and I'm using "unless: simplecheckcmd" to avoid executing it. The cmd.run also have a few 'require' states. However, I would like to setup my states so the requisits are not actually used if the 'unless' command succeeds. Is this doable?
14:15 jasonrm joined #salt
14:16 jasonrm joined #salt
14:23 flebel joined #salt
14:26 ProT-0-TypE joined #salt
14:26 lcavassa joined #salt
14:29 mpanetta joined #salt
14:33 iwishiwerearobot joined #salt
14:34 rojem joined #salt
14:38 ajolo joined #salt
14:38 seydu joined #salt
14:39 micah_chatt joined #salt
14:40 mgw joined #salt
14:43 iggy no
14:44 rojem joined #salt
14:45 alexr__ joined #salt
14:48 perfectsine joined #salt
14:49 kusams joined #salt
14:50 brayn_ joined #salt
14:51 ndrei joined #salt
14:52 epcim joined #salt
14:52 MrFuzz joined #salt
14:53 bigl0af joined #salt
14:54 XenophonF so i noticed https://github.com/saltstack/salt-macrepo
14:54 XenophonF but it's empty :(
14:54 XenophonF so is macrepo support coming to salt some day?
14:56 dRiN joined #salt
14:56 brayn joined #salt
14:57 __gotcha joined #salt
15:00 gmcwhistler joined #salt
15:01 teebes_ joined #salt
15:02 dude051 joined #salt
15:02 karimb joined #salt
15:02 housl joined #salt
15:04 linjan joined #salt
15:07 perfectsine joined #salt
15:11 __gotcha joined #salt
15:11 b1nar1 joined #salt
15:12 Katafalkas joined #salt
15:14 jaimed joined #salt
15:14 TTimo joined #salt
15:16 iwishiwerearobot joined #salt
15:19 TTimo hello everyone. best practice question .. I have some configuration files that I want salt to modify/edit. for small edits I would use file.replace, blockreplace etc.
15:19 TTimo but this is a large file with a lot of edits
15:19 TTimo so I'm thinking maybe I could just have it processed by jinja
15:20 TTimo I can probably figure out a way to have salt invoke a command to get the jinja processing done
15:20 TTimo is there a better way to do that? processing some random file with jinja from salt, or generally doing more advanced customization to a config file
15:21 srage_ joined #salt
15:22 TTimo oh actually
15:22 TTimo I missed this small paragraph in the docs, looks like I can do that easily :)
15:23 iggy managed with a source and template: jinja
15:23 TTimo yes
15:24 TTimo does that mean the grains stuff I can do in my .sls files I can do there too
15:24 iggy if you haven't already, you might try looking through some of the https://github.com/salt/saltstack-formulas
15:24 djstorm joined #salt
15:24 iggy most of them heavily use jinja templates
15:24 karimb joined #salt
15:25 imanc if I'm including a sls file with include: theslsfile     and later on need a state to depend on that included state, can I just do: require: \n\t- include: theslsfile ?
15:26 iggy sls: thefile
15:27 imanc iggy:  cheers.  It's actually a directory/package ... .with an init.sls in it. So would the same format work?  sls: thefile ?
15:28 iggy yeah, whatever format you'd use in (f.ex.) the top file
15:29 krak3n` joined #salt
15:29 steffo joined #salt
15:31 bhosmer joined #salt
15:32 kermit joined #salt
15:34 giomanda joined #salt
15:38 babilen TTimo: What kind of file is it?
15:38 SheetiS joined #salt
15:40 TTimo oh just some horrible legacy php config
15:40 TTimo where I need to drop a bunch of IPs, hostnames, etc.
15:42 bastion1704 joined #salt
15:43 rlarkin I've tried to write a reactor two ways: http://pastebin.com/Dk9yFJDy
15:44 rlarkin but both ways give me an error: 'return': 'Exception occured in runner state.orchestrate: SaltInvocationError: orchestrate takes at least 1 argument (0 given)',
15:45 babilen TTimo: Yeah, file.managed with "template: jinja" sounds like the best idea then. Keep variable bits in a pillar and then use {% set php_foo = salt['pillar.get']('some:php:pillar', {}) %} at the beginning and later {{ php.foo.get('some_value', DEFAULT_VALUE) }} in the file itself
15:45 babilen TTimo: You can, naturally, use other styles of accessing values in the pillar (just wanted to give an example)
15:45 KennethWilke joined #salt
15:46 iggy or use the mine
15:46 babilen Yeah, the mine would be appropriate for values from other minions .. you will probably also require values from grains
15:46 dude051 joined #salt
15:46 perfectsine joined #salt
15:47 iggy {% set dbhost = salt['mine.get']('G@tags:db and G@tags:primary', 'network.interfaces', 'compound') %}
15:47 babilen rlarkin: Make the web a better place and stop using pastebin.com! There are many better alternatives such as http://refheap.com, http://paste.debian.net, http://bpaste.net, https://gist.github.com, ...
15:47 iggy as an example
15:47 linjan joined #salt
15:48 rlarkin ok
15:48 rlarkin !
15:48 babilen I should embrace the mine more ;)
15:48 _jslatts joined #salt
15:48 cleme1mp joined #salt
15:49 Katafalkas joined #salt
15:49 dude051 joined #salt
15:49 iggy I've never seen an example of running the orchestrate runner from a reactor
15:50 babilen me neither and I am just trying to decide if that's my fault or simply not possible :D
15:51 rlarkin so it should be in the startup state then?
15:51 babilen Can you call runners from there? I have, as of now, only used execution modules in my reactors
15:51 cleme1mp joined #salt
15:52 rlarkin my deploy script fires a 'deploy' event so I can run highstate just once and not whenever the minion service restarts.  I want to sync grains and then run highstate.
15:52 hobakill1 joined #salt
15:53 rlarkin I tried putting my grains as the startup state , and then call highstate from grains.  that failed.
15:53 rlarkin now I'm trying orchestrate
15:53 rlarkin I'm pretty sure I'm 'doing it wrong' , everyone else must want to do the same thing right?
15:54 thedodd joined #salt
15:54 rspectre joined #salt
15:55 iggy you can run multiple states in response to an event
15:56 badon joined #salt
15:56 iggy - 'salt/minion/*/start':    - /srv/reactor/sync_all.sls    - /srv/reactor/graphite_event.sls
15:56 ghanima joined #salt
15:57 iggy unless you are specifically trying to orchestrate things over multiple hosts, I'd do that
15:57 forrest joined #salt
15:58 rlarkin and one of those states can be 'highstate' ? when I tried that , highstate would fail because a state was already running.
15:58 iggy hmmm, that I don't know
15:58 iggy we have highstate in our minion startup
16:00 iggy oh, no, in our sync_all.sls we have saltutil.sync_all, mine.update, and state.highstate
16:00 hasues joined #salt
16:00 iggy I can't swear that it's running though
16:00 iggy I should probably double check
16:00 forrest Why are you breaking stuff so early iggy?
16:01 rlarkin I actually tried doing a cmd.run that called a script , that backgrounded, hoping the state would return, and the backgrounded script would sleep then salt-call highstate.
16:01 iggy IT'S FRIDAY! I DO WHAT I WANT!
16:01 iggy oh, yeah, that definitely won't work
16:01 rlarkin didn't work.  the state actually waited for the backgrounded task to finish
16:01 forrest Yeah? Lots of prod deploys?
16:01 forrest rlarkin: what are you trying to do?
16:02 forrest sorry I just hopped in
16:02 iggy sync/highstate on boot (vs minion startup)
16:03 forrest http://docs.saltstack.com/en/latest/ref/states/startup.html
16:03 forrest why not use startup states?
16:03 rlarkin salt-cloud deploy, custom 'deploy' event in my boostrap script , on_deploy populate /etc/salt/grians , sync, then run highstate.  only on initial deployment , not on minion_start
16:03 forrest ahh
16:03 iggy forrest: because that's on minion startup, not system startup
16:04 forrest iggy: so? Install the service, init it on, service starts, runs your startup states.
16:04 iggy I'm not the one trying to do it
16:04 forrest Pretty sure that Ryan had a post on this
16:04 forrest iggy: I know
16:04 forrest iggy: I'm just saying :P
16:04 iggy yeah, I just do all that on minion start
16:04 forrest rlarkin: http://ryandlane.com/blog/2014/09/02/saltstack-patterns-grainstate/
16:04 rlarkin I wanted to be able to restart minion-salt and not do highstate
16:04 forrest there you go, ryan is doing it right there where he has a grain
16:05 rlarkin thnks forrest
16:05 forrest rlarkin: YAR
16:05 forrest like a pirate
16:05 ndrei joined #salt
16:05 racooper joined #salt
16:05 forrest he's just using a grain and then setting it, pretty good workaround really.
16:05 eriko joined #salt
16:05 pipps joined #salt
16:07 kusams joined #salt
16:07 * iggy goes back to actually fixing his own problems
16:07 forrest iggy: Why so many problems iggy :\
16:08 forrest It's Friday
16:08 iggy sadly, it's something I fixed at one point, but apparently didn't commit the changes, and now it's broken again :(
16:08 iggy fml
16:09 forrest commit all the things man
16:11 XenophonF i wonder if i can combine an accumulator with a file.managed state...
16:13 XenophonF ah of course i can
16:13 XenophonF awesome
16:16 bhosmer joined #salt
16:17 alexr___ joined #salt
16:19 unpaidbi1l Hi guys, is there any way to set up a mapping file that is compatible with both mako and jinja templates or a generally accepted way to create a mapping/defaults file for a mako template by itself?
16:20 renoirb Is there an example somewhere of a salt runner over a specific state.sls ?
16:23 forrest unpaidbi1l: http://docs.saltstack.com/en/latest/ref/renderers/#composing-renderers
16:23 repl1cant quick question
16:23 hasues left #salt
16:24 repl1cant is there a way to make the default behaviour of state.highstate as --state-output=mixed state.highstate?
16:24 repl1cant without writing an alias? :-)
16:24 diegows joined #salt
16:24 repl1cant was thinking something in /etc/salt/master
16:25 unpaidbi1l That won't work from file.managed will it?  If I've got a state that has a defaults.jinja file that defines a rawmap in yaml and merges pillar data that is used n jinja templates, I couldn't use jinja|mako in my file.managed to load the defaults with jinja and then use that data for the mako parts, could I?
16:25 forrest repl1cant: not that I'm aware of.
16:26 forrest unpaidbi1l: Can you try to explain what it is that you're trying to do?
16:28 unpaidbi1l maybe my problem is that i'm going against the gran here.  the problem I have is that i'm using the syslog-ng salt formula, it uses mako templates to render the configuration file.  then in my other states that use syslog logging, i include the syslog-ng configuration template to create a service specific syslog-ng configuration.  in these other modules i have defaults, but they're all created as jinja templates using load_yaml as rawmap, then merges a salt
16:28 tligda joined #salt
16:29 alexr__ joined #salt
16:29 unpaidbi1l in this case, i want the ability to define a default syslog configuration that can be overridden by pillar data
16:29 unpaidbi1l it works fine if i just include the pillar data by default, but i want the data to be optional to reduce the size of my pillar
16:30 unpaidbi1l and to make the configuration of services less of a burden
16:31 unpaidbi1l i suppose i could just make the syslog defaults a mako template, they arent really used anywhere else, but i was hoping there was an option that would give me the best of both worlds
16:32 StDiluted joined #salt
16:32 pravka joined #salt
16:33 atbell joined #salt
16:33 forrest unpaidbi1l: Ahh I see what you mean, I didn't realize the syslog-ng formula used mako...
16:35 unpaidbi1l yeah, so in the ideal scenario i would change the way i define default values so they could be used by either mako or jinja templates.  otherwise i will make the syslog-ng defaults in a mako template and include it the mako syslog-ng configs
16:36 unpaidbi1l i'm rooting around now to see if there's a function i can call that will load a file from the salt master and parse it as yaml, that would be usable in both jinja and mako, and might have the benefit of caching the parsed structure for the duration of the run
16:39 MrFuzz joined #salt
16:40 bezeee joined #salt
16:41 rojem joined #salt
16:42 Ahlee hrm.  Can you specify timeouts in states if you know they're going to take a long time?
16:43 forrest Ahlee: not in states as far as I know, only when you call them
16:47 vlcn joined #salt
16:50 Ahlee yeah, that's what I just came up with
16:50 Ahlee bummer, but expected
16:50 Ahlee tis why i alias salt='salt -t 300'
16:56 racooper joined #salt
16:58 jngd joined #salt
16:59 kermit joined #salt
17:03 pipps joined #salt
17:04 housl joined #salt
17:05 gpmidi joined #salt
17:06 micah_chatt_ joined #salt
17:07 meylor joined #salt
17:09 dergrunepunkt joined #salt
17:10 dergrunepunkt I get this message:  "Comment: State keystone.endpoint_present found in sls openstack.keystone is unavailable", ideas?
17:11 gpmidi Hey, I'm having trouble getting states working. It might have to do with file transfers. I have basic commands working (cmd.run, test.ping, etc) but whenever I try to use states to install vim via states (salt '*' states.sls vim) it says that it can't find it with: "No matching sls found for 'vim.sls' in env 'base'". I've tried putting the vim.sls file in /srv/salt, /srv/salt/base, and in a git repo without any luck. For each of those tests I made what
17:12 StDiluted gpmidi: sometimes it gives that error for other reasons, have you run with a debug?
17:13 gpmidi Yup, on both the minions and the master
17:13 gpmidi Here is a clip of what I think is relivant. Will post full in a moment. https://gist.github.com/gpmidi/f5006d4828fed7f31c33
17:14 StDiluted oh
17:14 StDiluted try making a directory /srv/salt/vim then change vim.sls to init.sls
17:14 StDiluted then call state vim
17:15 StDiluted I don’t know how other people do it but I try to keep my /srv/salt directory pretty barren, and make directories for states
17:16 SpX joined #salt
17:16 gpmidi no joy, same error: https://gist.github.com/gpmidi/011fdd914b5086cc31ca
17:16 mpanetta joined #salt
17:17 zlhgo joined #salt
17:17 StDiluted can i see your init.sls
17:18 gpmidi sure, one moment
17:18 gpmidi https://gist.github.com/gpmidi/011fdd914b5086cc31ca
17:18 kickerdog joined #salt
17:18 StDiluted same link you just posted
17:19 gpmidi I updated the gist with a second file
17:19 StDiluted ah, it’s not showing
17:19 iggy you know gist's allow for multiple files... paste everything relevant up front to make it easier us
17:19 gpmidi oh try now
17:20 bhosmer joined #salt
17:20 gpmidi iggy: Good point
17:20 iggy (it even supports drag and drop, so just drop a bunch of files on the gist and BAM!)
17:21 StDiluted hrm
17:21 StDiluted that seems weird to me that it’s not working.
17:22 StDiluted and you’re doing salt ‘*’ state.sls vim as your command line?
17:22 gpmidi no, using the fqdn of the target system
17:22 spookah joined #salt
17:22 gpmidi but I've tried '*' before a few times without any luck
17:22 gpmidi it fails on all except the minion on the master
17:23 StDiluted what’s file_root set to in /etc/salt/master
17:23 gpmidi Lemme get you a copy of the configs and debug logs
17:23 StDiluted sorry file_roots
17:24 iggy you still need to target that file at the minion (or include it)
17:24 kickerdog It would be so cool to a have docs generator that would create a html site out of your salt/pillar dirs
17:24 gpmidi iggy: I thought roots transfered it
17:24 wendall911 joined #salt
17:26 KyleG joined #salt
17:26 KyleG joined #salt
17:26 gpmidi StDiluted: I updated the gist with the master config as well as trace logs from both minion and master during a test: https://gist.github.com/gpmidi/011fdd914b5086cc31ca
17:26 baconbeckons joined #salt
17:27 possibilities joined #salt
17:27 iggy so what command are you running that gives you that error? and what does your top file look like? (and what version of salt out of curiosity)
17:27 mpanetta joined #salt
17:28 gpmidi On the server: 0.17.5 On the client: 2014.1.13
17:28 StDiluted gpmidi: looks like you have file_roots set to /srv/salt/base
17:28 gpmidi The command: salt stor14.gpmidi.net state.sls vim
17:29 iggy you can't do that
17:29 kickerdog looks wonky
17:29 iggy run newer minions than master
17:29 lempa joined #salt
17:29 StDiluted so for your command to work
17:29 StDiluted you need /srv/salt/base/vim/init.sls
17:29 gpmidi StDiluted: I'd tried it like that earlier without it working. But it sounds like iggy has found the real reason.
17:29 StDiluted and yeah, your master cant be lower than minions or you run into all osrts of issues
17:30 gpmidi tbh, I'd assumed that 14.04 would have had a newer version that EPEL for 6.x
17:30 aparsons joined #salt
17:30 gpmidi So, thanks guys. I'll see about updating the master.
17:30 iggy there's a ppa somewhere
17:31 gpmidi iggy: Yeah, I think I saw it in the install docs. Shouldn't be too hard.
17:32 gpmidi I'm just still in shock that RHEL/CentOS is ahead of Ubuntu for even one package
17:33 sarlalian joined #salt
17:34 kickerdog gpmidi: might consider using the bootstrap
17:34 smcquaid joined #salt
17:35 gpmidi I'll check out bootstrap too, thanks
17:35 kickerdog wget -O install_salt.sh https://bootstrap.saltstack.com; sudo sh install_salt.sh
17:35 iggy rhel is not... epel is
17:35 kickerdog That install distribution stable
17:35 iggy epel ~= fedora packages
17:37 kickerdog left #salt
17:37 kermit joined #salt
17:37 lemoi joined #salt
17:38 intellix joined #salt
17:38 nickjj joined #salt
17:38 meylor joined #salt
17:39 gpmidi At this point, regardless of the actual liniage of the packages, I think of EPEL as part of RHEL/CentOS because the base repos alone are missing a lot of stuff that I prefer having. But yes, you're quite right that it's not actually part of it.
17:40 gpmidi The updated salt-master package fixed my problem. Thanks again. :)
17:40 troyready joined #salt
17:40 iggy ^5
17:40 jalbretsen joined #salt
17:41 iggy for future reference, things are mostly backward compatible the other way (i.e. minions older than master)
17:48 kermit left #salt
17:50 dooshtuRabbit joined #salt
17:53 Gareth morning morning
17:53 _prime_ Was disappointed to see compound matches removed from 2014.7 (we use them in our top files and quite extensively at the commandline to run batch commands on various machines by various criteria).  Any word on when 2014.7.1 will be out, with compount matching and pillar matching re-enabled?
17:55 iggy _prime_: they are only removed from mine and compound.compound calls
17:55 Gareth _prime_: it sounded like they weren't completely removed, just disabled for certain areas where they were issues.
17:55 Gareth what iggy said. :)
17:55 iggy that said, a proper fix was being worked on yesterday
17:55 iggy after we got out the pitch forks ;)
17:55 iggy torches and pitch forks that is
17:56 _prime_ so I can still do a 'salt -C 'I@key:subkey:val and G@key:subkey:val' ?
17:56 Gareth _prime_: should be able to.
17:56 _prime_ and more importatly, use it in my top file with I@environment:dev and G@environment:dev?
17:56 iggy as long as your command after that isn't mine.* or compound.compound
17:56 rojem joined #salt
17:56 _prime_ cool!
17:57 _prime_ when I read the release notes I groaned...thought we'd have to wait a month or two before doing any real testing of 2014.7.  Glad to hear I misread that!
17:57 iggy it mostly impacts things like: {% set dbhost = salt['mine.get']('G@tags:db and G@tags:primary', 'network.interfaces', 'compound') %}
17:57 _prime_ iggy: OK, cool, that won't hold us up too much then.  thanks!
17:59 iggy sadly, it does us
17:59 iggy but we were unlikely to switch to 2014.7 any time soon anyway
18:00 _prime_ we probably won't go into production before .1 (or at least several weeks of testing .0), but we do want to push forward aggressivley.  I like the saltnado api and cherrypy enhancements.  but yeah, lots of testing first :-)
18:01 _prime_ and of course we use the pepa external pillar heavily (I was surprised it wasn't mentioned in the release docs now that it's a part of salt too).
18:08 Ryan_Lane joined #salt
18:10 mapu joined #salt
18:11 beneggett joined #salt
18:11 aqua^mac joined #salt
18:11 carmony joined #salt
18:16 murrdoc joined #salt
18:19 aparsons_ joined #salt
18:24 cpowell joined #salt
18:27 XenophonF hey does anyone here use winrepo with git?
18:28 XenophonF i'm trying to deploy software stored in the git repository, but it isn't working like i think
18:28 XenophonF https://github.com/ibrsp/salt-winrepo/tree/master/panorama9
18:28 iwishiwerearobot joined #salt
18:33 aw110f joined #salt
18:33 XenophonF salt sees the package definition, but minions can't download the MSI file
18:33 XenophonF which is also stored in Git
18:34 iggy just you...
18:34 XenophonF https://github.com/ibrsp/salt-winrepo/tree/master/panorama9/files is where the installer lives
18:34 XenophonF which i assumed would translate to salt://win/repo/panorama9/files/P9Agent.msi
18:35 iggy I'm assuming you have something in gitfs for this?
18:35 murrdoc no clue what your /srv/salt/path/ is
18:36 XenophonF here's the error i get: https://bpaste.net/show/937c905f9572
18:36 XenophonF iggy, here's the master config - https://github.com/ibrsp/salt-states/blob/production/salt/files/master-overrides.conf
18:37 iggy so where are you getting the win/repo/ in front of panorama9 from?
18:37 XenophonF do I need to add my windows repo to the gitfs_remotes list?
18:37 * iggy butts out...
18:37 iggy I know nothing about win_repos
18:38 XenophonF iggy: quite frankly i'm just copying and pasting the 7zip example from http://docs.saltstack.com/en/latest/topics/windows/windows-package-manager.html
18:38 XenophonF i'm kinda in the same boat as you :-/
18:38 iggy buy try cp.list_master
18:38 murrdoc [ERROR   ] Unable to cache file 'salt://win/repo/winrepo.p' from saltenv 'base'.
18:38 XenophonF babilen or hobakill were working on this a while back
18:38 murrdoc the path is off
18:38 clinta joined #salt
18:39 skyler joined #salt
18:39 XenophonF that's what i figured
18:39 XenophonF but i don't know what the path is supposed to be
18:40 iggy 13:38 < iggy> buy try cp.list_master
18:40 murrdoc cp.list_master
18:40 murrdoc :D
18:40 murrdoc 10:40 <iggy> 13:38 < iggy> buy try cp.list_master
18:40 murrdoc this is fun
18:41 XenophonF sorry can't read
18:41 XenophonF that just comes back with https://bpaste.net/show/c9b8da5da485
18:42 XenophonF same result when i run it on both the master and the minion
18:42 XenophonF so do i need to add the winrepo to gitfs_remotes?
18:42 murrdoc yeah
18:47 XenophonF will that conflict with my state tree?
18:48 XenophonF i have a salt-states repo that also has a panorama9/init.sls in it
18:48 XenophonF technically, that's in the development branch
18:51 XenophonF maybe i'd be better off serving these files to minions over http?
18:55 dude^2 joined #salt
18:59 thayne joined #salt
19:00 otter768 joined #salt
19:01 intellix joined #salt
19:03 Mso150 joined #salt
19:03 pipps joined #salt
19:03 XenophonF it isn't really clear from the gifs/winrepo documentation how best to serve files out of the winrepo when it's in git
19:04 murrdoc can you drop it locally  ?
19:04 murrdoc use a file.managed to drop it on the box
19:04 murrdoc and then install
19:04 murrdoc and then remove
19:05 thedodd joined #salt
19:07 XenophonF got the same error even after adjusting gitfs_remotes
19:07 XenophonF so that's not right
19:07 XenophonF murrdoc: i could, but i'm not sure i want to
19:07 XenophonF for now i'm going to just pull it from github.com via blobstorage and call it done
19:08 kusams joined #salt
19:08 bhosmer joined #salt
19:08 XenophonF it's possible i don't have win_repo_mastercachefile set correctly
19:09 iggy it's possible nobody really understands how the windows stuff works at all
19:11 epcim joined #salt
19:11 XenophonF hah
19:12 XenophonF well, I'm going to change that
19:12 XenophonF for me Salt's most important feature is that it works on Windows and Unix
19:12 XenophonF so I'm going to figure this out
19:13 XenophonF now that I've RTFMed some more, I wonder if I'm running into problems because I have fileserver_backend set to just git
19:13 XenophonF instead of git and roots
19:13 XenophonF oh man
19:13 XenophonF that's probably it
19:17 XenophonF yeah, that's it
19:17 jalbretsen joined #salt
19:18 XenophonF https://bpaste.net/show/24bbe0469792
19:18 murrdoc yay
19:18 teebes joined #salt
19:18 murrdoc yay ?
19:18 XenophonF so the win_repo_mastercachefile is served out of salt's file_root
19:19 Mso150 joined #salt
19:19 XenophonF so that means the right URL for my MSI package must be salt://win/repo/salt-winrepo.git/panorama9/files/P9Agent.msi
19:23 XenophonF shoot forgot to run 'git push'
19:24 badon joined #salt
19:24 Reiner036 joined #salt
19:24 murrdoc XenophonF:  i would call the day
19:24 murrdoc its looking like one of those days :)
19:26 ckao joined #salt
19:28 Reiner037 joined #salt
19:28 XenophonF NEVER GIVE UP!  NEVER SURRENDER! http://i.imgur.com/24q41.jpg
19:28 murrdoc hahah
19:28 murrdoc well u work with windows
19:28 murrdoc so you know
19:28 KyleG joined #salt
19:28 KyleG joined #salt
19:28 murrdoc i already respect your commitment
19:28 murrdoc (hug)
19:28 murrdoc brb
19:29 KyleG joined #salt
19:29 KyleG joined #salt
19:29 XenophonF suspect! https://bpaste.net/show/a13815f90efe
19:29 XenophonF er
19:29 XenophonF i mean, success!
19:29 XenophonF LOL
19:30 XenophonF thanks for the love, murrdoc :)
19:31 otter768 joined #salt
19:32 baconbeckons joined #salt
19:33 sbernardin joined #salt
19:34 sbernardin left #salt
19:35 elfixit joined #salt
19:35 iggy you should send PRs to improve the docs
19:40 kickerdog joined #salt
19:43 rypeck Saltstack doesn't specifc the requirement of a specific version of jinja2 for requirements... but Jinja 2.7 has some awesome new features.
19:43 XenophonF fo sho
19:45 kickerdog joined #salt
19:46 sbernardin78 joined #salt
19:51 badon joined #salt
19:51 murrdoc joined #salt
19:51 ph8 joined #salt
19:52 glyf joined #salt
19:54 Reiner037 joined #salt
19:55 pipps joined #salt
19:55 giantlock joined #salt
19:56 bezeee joined #salt
20:00 aqua^mac joined #salt
20:01 iggy rypeck: the nice thing is you can use whatever version you feel like going through the trouble of installing... and whatever features it has, you should have available to you
20:02 rypeck iggy: that was my initial though - thanks for confirming. I submitted a launchpad question to see if they'll upgrade from Jinja 2.6 on Ubuntu 12.04 to 2.7 - I'd like to avoid the "trouble of installing" for what I do.
20:03 iggy hah!
20:03 iggy 12.04 is an LTS
20:03 iggy if they randomly upgrade packages on that, they are shooting themselves in the foot
20:04 rypeck One can hope.
20:05 iggy it's easy enough to install with pip
20:05 rypeck It's for a security onion's onionsalt package - if I went that route - everyone would have to.
20:06 rypeck I have hope! foolish hope
20:13 baconbeckons joined #salt
20:16 kickerdog joined #salt
20:17 TheThing joined #salt
20:17 kickerdog joined #salt
20:18 jalaziz joined #salt
20:18 kickerdog1 joined #salt
20:21 Mso150 joined #salt
20:22 ndrei joined #salt
20:27 pipps99 joined #salt
20:27 murrdoc joined #salt
20:31 pipps joined #salt
20:36 tristianc joined #salt
20:36 badon joined #salt
20:38 baconbeckons joined #salt
20:49 Katafalkas joined #salt
20:49 XenophonF rypeck: onionsalt?
20:49 * XenophonF googles it.
20:49 * XenophonF has high hopes...
20:50 XenophonF https://code.google.com/p/security-onion/wiki/Salt sounds really interesting
20:50 rypeck XenophonF: you already a security onion user?
20:52 XenophonF rypeck: yes
20:57 Mso150 joined #salt
20:57 bhosmer joined #salt
20:59 kickerdog joined #salt
21:01 badon_ joined #salt
21:02 wendall911 joined #salt
21:03 kickerdog1 joined #salt
21:04 kickerdog joined #salt
21:05 Mso150_d joined #salt
21:09 TheThing joined #salt
21:09 thawes joined #salt
21:10 b1nar1 joined #salt
21:11 ajolo joined #salt
21:17 stan_k I feel like there are a number of ways to do this, but which is the most simple?   run a command on the master if the retcode of a minion is not 0.  (given a pure out of the box master/minion setup as a base)
21:17 stan_k possible better alternative would be "run some python on the master if the retcode of a command on the minion is not 0"
21:20 meylor1 joined #salt
21:21 iggy hmmm, the master/minion side of that is going to make it tough
21:22 SheetiS stan_k: I am not sure about most simple, but the reactor can see returns and get the retcode from them.
21:24 SheetiS http://docs.saltstack.com/en/latest/topics/reactor/ with something like this for something to react to:  https://bpaste.net/show/4b8c7b17f294
21:24 SheetiS then the post_execution.sls could be something written in the py renderer easily if you wanted to run python code there
21:24 iggy you could use a reactor and key off an event with a failed status... ^ got sidetracked
21:27 SheetiS This is a small snippet from my reactor that does something similar: https://bpaste.net/show/232a6dce8674
21:27 SheetiS That is a pure jinja|yaml sls file where I call a state
21:30 eagen joined #salt
21:30 intellix joined #salt
21:31 kusams joined #salt
21:32 berserk joined #salt
21:35 pipps joined #salt
21:39 Pixionus So I have something odd going on here and could use some help I think. I have a set of minions that I just switched on and they are showing that their keys were rejected by the Master (after a period where they were saying the keys were cached) and I haven't seen them appear on the master key list or the master's logs.
21:40 Pixionus I am able to see the WAN from those minions, I am able to ssh in and ping out, but I don't know how they think the key was rejected since our Master doesn't seem to have ever heard of them.
21:42 dude051 joined #salt
21:43 baconbeckons joined #salt
21:43 SheetiS Pixionus: they each have a unique minion_id with no overlap, correct?  also would want to verify that the minion config has the proper master configured (not sure if you have multiple environments in your network with different masters).  Finally you could always try and purge the pki directory on the minions with their salt-minion service stopped (/etc/salt/pki default on linux systems), then restart the minion.
21:45 Pixionus The minion id's are based on their MAC addresses and the addresses are of course all different.  I checked and the minion config is pointed to the correct public ip.
21:45 Pixionus I need to figure out what is causing it so that this image is plug and play for the end users.
21:46 SheetiS is the minion pre-installed on the image?
21:46 SheetiS or are you installing it as part of a bootstrap?
21:46 Pixionus preinstalled, but I made sure it has no minion id or keys
21:47 Mso150_d joined #salt
21:48 SheetiS which OS for the image, and also which salt version?
21:48 Pixionus Debian Wheezy
21:49 aqua^mac joined #salt
21:50 Pixionus pastebin.com/eYH37VKM
21:50 Pixionus --versions output to pastbin
21:51 Pixionus actually: http://pastebin.com/tXBzg4w3
21:51 Pixionus has master and minion
21:51 SheetiS How are you setting the minion id?  I've seen where a minion id based upon a MAC ends up getting processed weirdly by pyyaml.  Usually this is solved by putting it in single quotes in the config.
21:52 Mso150_d_y joined #salt
21:52 Pixionus Not actually sure.  We are using embedded systems by Technologic Systems and some of their custom stuff sets that up.
21:53 Pixionus Ill try adding it to the config and restarting the server.
21:53 SheetiS is it set in /etc/salt/minion as the id: <whatever> or is it in the /etc/salt/minion_id?
21:53 Pixionus minion_id
21:54 jalaziz joined #salt
21:54 Pixionus Ah shiiite...
21:54 Pixionus yeah it's set oddly there.
21:54 Pixionus ok, thanks.  I can get to the bottom of this now and stop bashing my head on a brick wall when the door is right next to me...
21:55 karimb joined #salt
21:56 skarn joined #salt
21:56 kballou joined #salt
21:58 Pixionus Not sure if you care to know but it might just help someone:  So as part of my process, I delete all server specific stuff before shutting down server when I build an image (including minion_id) so I never suspected that file to be set wrong.
21:58 Pixionus Turns out that somehow, it got recreated with the build boards hostname even though I had deleted the file
21:58 Pixionus before I shut down.
21:59 Pixionus stupid mistake, but not sure how it would happen.
21:59 XenophonF left #salt
22:00 Pixionus Thanks again SheetiS
22:00 iggy did you delete the file before the minion was stopped? it might write it out on shutdown
22:01 Pixionus Iggy that's what I suspect.  I was just doing it last thing before shutting down.  Honestly until this last build I always just pulled the plug, rather than safe shutdown, but since I was building the golden image this time I followed proper procedure to prevent any possible corruption since it mattered.
22:02 Pixionus I suppose Ill just mount the image itself and remove the files directly from it this time and maybe run a test or two to see if it is writing on shutdown somehow.
22:03 iggy the easiest test?
22:03 Pixionus We have monit keeping Salt alive, so it could have been part of the equation as well this time.
22:03 iggy oh
22:03 iggy I was going to say just rm file then stop service
22:03 iggy if the file is there after that...
22:04 Pixionus yeah, Ill remove, shutdown, then just stick the sd into my computer and check to see if the files exist.
22:04 teepark I'm trying to make sense of gitfs_pubkey and gitfs_privkey -- they're documented as pygit2 only, but since installing pygit2 on my salt master it tells me "This transport isn't implemented. Sorry" about ssh:// repos
22:04 Pixionus but first, I'll get these servers out the door.
22:04 micah_chatt joined #salt
22:04 teepark ssh keys aren't usable via any other transport, are they?
22:04 iggy teepark: what version of salt?
22:04 teepark 2014.7.0
22:05 teepark .pygit2 0.21.4
22:05 iggy did you change the master to use pygit as well (just installing it isn't enough afaik)
22:06 teepark docs say it'll prefer pygit2 if it's available, but I also set gitfs_provider to make sure
22:06 iggy then I got nothing
22:06 iggy I'm still on 2014.1
22:07 iggy so we have to use ssh config aliases
22:08 teepark yeah I only bumped forward the version to get the extra gitfs config versions and per-remote params
22:09 to_json joined #salt
22:18 catpig joined #salt
22:23 kermit joined #salt
22:24 thawes joined #salt
22:25 renoirb The Salt Mine component is exactly what I needed, that’s amazing!
22:25 renoirb #randomlove
22:29 jhauser joined #salt
22:30 atbell joined #salt
22:32 holler joined #salt
22:33 holler hello, how is apt-get update handled in salt? I want to make sure that is run before installing packages, does it do it automatically?
22:34 StDiluted what version are you using, holler
22:35 holler StDiluted: v2014.1.13
22:35 StDiluted ah, well, they added salt.states.pkg.uptodate in 2014.7, so you wont have that
22:36 holler wait 2014.7? hows it at .7 already
22:36 Ryan_Lane joined #salt
22:36 StDiluted it’s RC
22:36 _prime_ Maybe it was optimistically going to be released in July :-)
22:37 _prime_ but no salt (or wine) shall be served before its time?
22:37 holler interesting.. so I should upgrade to 2014.7? I was setting specific version in my vagrant file bc of a bug in .12
22:37 holler 1.12
22:37 holler oh
22:37 Katafalkas joined #salt
22:37 holler so in the meantime should I just do cmd.run?
22:37 thawes joined #salt
22:38 StDiluted holler: https://github.com/saltstack/salt/issues/9341
22:38 StDiluted maybe pkg.latest Refresh=True?
22:40 graph1x joined #salt
22:41 MrFuzz joined #salt
22:42 babilen holler: it is, no need for pkg.latest -- in fact I wouldn't recommend to make upgrades part of the highstate
22:42 babilen (just wtach the minion's debug logs)
22:44 thawes_ joined #salt
22:46 bhosmer joined #salt
22:46 cads joined #salt
22:47 jcl joined #salt
22:48 jcl Hey, does anyone have experience running Salt in AWS?
22:48 jcockhren o/
22:48 jcockhren jcl: what's your question?
22:49 Ryan_Lane jcl: I have quite a bit
22:49 jcl I'm working on a new environment in AWS and currently using 4 EC2 instances. However, I'm getting very inconsistent responsiveness between the master and the agents.
22:49 Ryan_Lane ah. sorry. i run without a master
22:49 jcl Running manage.status varyingly shows systems as up or down and it can change each run.
22:50 jcockhren jcl: salt is very sensitive in terms of the matching versions of the master and minions
22:50 jcl I've just built all four instances and they're identical.
22:50 jcockhren cool.
22:50 jcockhren also, there are some salt versions that are known to have inconsistent communication
22:50 _prime_ i've seen this too jcl, jcockhren.  running in a multi-master environment 2014.1.13, some minions respond to pings, others do not
22:51 jcl I'm on 2014.1.13+ds-1trusty1 on Ubuntu 14.04..1
22:51 jcockhren outside of those 2 concerns, there's nothing special about running in AWS
22:51 jcl It's a single master with the 4 minions
22:51 StDiluted I’ve had similar issues
22:51 StDiluted sometimes the minions just dont respond
22:51 _prime_ StDiluted: yes, it's weird.  I'm really hoping 2014.7 fixes this...
22:52 jcl Often even the master's minion doesn't respond!
22:52 jcl Is there an ETA yet on .7?
22:52 StDiluted I’m using 2014.7
22:52 StDiluted it still happens sometimes
22:52 nitti_ joined #salt
22:52 _prime_ oh, that's a bummer.  maybe raet will help (but too early to make that leap for me anyway)
22:52 jcockhren 2014.1.7 was the most stable of the Hydrogrens
22:52 jcockhren (for me)
22:53 nitti_ joined #salt
22:53 fxhp joined #salt
22:54 jcl The odd thing is that I have about 40 servers in my main non-AWS environment and never see this problem.
22:55 pipps joined #salt
22:55 jcl And those are running a mix of 2014.1.10 through .13
22:55 jcockhren jcl: that is weird
22:55 jcl I do have an AWS security group rule allowing TCP ports 4505-4506 to all servers.
22:56 StDiluted i am on AWS and have seen this problem the entire year+ I’ve used Salt
22:56 jcl StDiluted: I'm glad to know it's not just me.
22:57 StDiluted the commands make it to the minion, they jsut never return a status
22:57 jcockhren I have my master in a non-AWS cloud and communication to the AWS stuffs have been smooth as long as I stay clear of certain versions
22:57 StDiluted or rather, the status never shows up at the master
22:57 StDiluted i see the test.ping happen on the minion
22:57 StDiluted it just never displays on the master console
22:59 jcl I just rebooted all 4 instances and running manage.status over and over sometimes shows all 4 as up and other times 2 (the same 2) as down
22:59 jchen happens to me all the time. I just test.ping a few times until all the minions start responding, then subsequent commands go through, nfi why
23:00 baconbeckons joined #salt
23:00 babilen jchen: https://github.com/saltstack/salt/issues/15415
23:01 babilen (daily key rotation and the need to re-authenticate afterwards. can be triggered by test.ping)
23:01 jchen oooooh, nice
23:02 jchen babilen: htanks ;p
23:02 jcl yeah in 2014.7 ping_on_keyrotate (or something like that) will be enabled by default
23:02 jeddi joined #salt
23:02 jcl but key rotation and the bug babilen linked doesn't expelain why mine toggle back and forth on runs seconds apart
23:03 babilen jcl: They do it to spite you
23:03 eliasp regarding 2014.7… does anyone know something about the state of 2014.7 in the Ubuntu PPA? so far nothing's there yet…
23:03 jcl babilen: wouldn't surprise me
23:03 babilen eliasp: It has not been packaged yet (just like the Debian packages)
23:03 jchen I see that sometimes as well. I also see instances where there are multiple minion daemons running on minions causing things to be run multiple times
23:04 baconbeckons joined #salt
23:04 eliasp babilen: yeah, was just wondering whether it's due to man-power or technical issues…
23:05 babilen There are no technical issues and I don't think it's right to go into other aspects
23:06 eliasp sure… didn't want to put any blame on anyone… it was more like a "I could probably lend a hand if man-power is the bottleneck" thing…
23:06 babilen suffice to say the "package this NOW" approach of salt's upstream is quite atypical in the open source environment and not necessarily something that's great for maintainers
23:06 eliasp babilen: I know how these things are going… have been packaging quite a bit for Gentoo for ~12 years
23:07 babilen It would, IMHO, be perfectly fine for salt to simply release their software and then let maintainers package it whenever they get around to it
23:07 eliasp I do fully agree… upstream shouldn't have (IMHO) not have to care about distribution packaging
23:07 babilen An argument I can think of to justify the current situation is that you would want the same version in heterogeneous environments
23:07 eliasp s/not//g
23:08 babilen But that's about it. It is a shame and also makes it harder for maintainers to cherry-pick bugfixes and simply patch their packages
23:08 _prime_ babilen - as another gentoo user, I use gentoo-prefix to achieve exactly that: identical salt + python + deps on everything from sl6 to fc20
23:08 eliasp babilen: exactly the situation here… Windows packages are 2014.7 ready and I wanted to give the aggregation features a try…
23:09 eliasp _prime_: hmm… not such a bad idea to deploy a Gentoo prefix installation everywhere ;)
23:09 _prime_ in an environment where even developers have root access, and make weird changes to things like core swig libraries (!!!) having salt in a completely separate and guaranteed-to-be-consistent environment is a lifesaver
23:09 babilen I also wouldn't mind joining the Debian packaging team, but not like this.
23:09 _prime_ eliasp :-D
23:09 eliasp _prime_: sounds like a not quite healthy environment ;/
23:10 forrest joined #salt
23:10 _prime_ it's very dynamic, very fast, and not normally an issue, but you have to bullet proof your stuff, esp. when people start messing with python and swig
23:11 eliasp _prime_: might be one of the few cases where I'd go for containerization ;)
23:11 _prime_ yes, i'm pushing that hard, but in the meantime i need salt to be stable
23:11 eliasp sure
23:12 _prime_ but I'd forgotten about gentoo-prefix until I hit this issue (developer changes affecting salt's behavior), and it's working like a charm.  It's pretty cool to see salt with python 2.7.8 and zeromq 4.0.4  on an old scientific linux box :-)
23:13 jcl Hmm, one difference I do see when minions don't return a response to the master (on a test.ping for example) is that in the minion debug log it shows the test.ping results along with a subsequent saltutil.find_job results with a DIFFERENT jid than the test.ping's jid
23:13 eliasp _prime_: yeah… "enterprise" environments can sometimes be quite ugly to work with
23:13 kickerdog joined #salt
23:14 _prime_ eliasp: very much so at times
23:14 nickg joined #salt
23:14 nickg how do i manually change a minionid for an existing host ?
23:14 eliasp nickg: on the minion in /etc/salt/minion
23:15 baconbeckons joined #salt
23:15 eliasp nickg: you'll have to re-key after that
23:15 micah_chatt joined #salt
23:15 eliasp nickg: also make sure there's no minion_id file (for auto-generated minion IDs) which will overwrite any settings in /etc/salt/minion
23:15 babilen nickg: Delete minion_ ... ^^^
23:16 kickerdog1 joined #salt
23:16 nickg ok so i really need to delete it and just re-add it
23:16 nickg that way i dont stomp on it the old id later
23:19 rojem joined #salt
23:20 kusams joined #salt
23:21 nickg hmm somehow the minion remembers its originaly ID.  I set the id manually so it would use it, but then i unset it and restarted and it reverted back :(
23:23 nickg ok there's the minion_id file yeah..
23:28 babilen kindly ask it to go away?
23:35 thawes joined #salt
23:36 blake joined #salt
23:37 nickg fixing the minion_id worked
23:37 nickg thanks
23:38 aqua^mac joined #salt
23:42 luckenbach joined #salt
23:42 badon joined #salt
23:43 jalaziz joined #salt
23:43 luckenbach Is it possible to pass a list of args to cmd.run via cherrypy's /minion end point? it seems to ignore anything after the first arg in a fun: cmd.run, arg=[blah,blah,blah]
23:45 aquinas joined #salt
23:45 whiteinge luckenbach: pass the -d arg= multiple times instead of the list
23:45 hal58th joined #salt
23:46 whiteinge -d arg=blah -d arg=blah2
23:48 catpig joined #salt
23:49 badon_ joined #salt
23:52 hal58th Hey all, I found a race condition that affects the minion key and have a question before I file a bug. In what conditions does salt-minion generate a key? I am creating two keys if I start the salt-minion and do a salt-call state.highstate in quick succession.
23:52 dergrunepunkt joined #salt
23:53 dergrunepunkt hi guys, how do I do to add a mysql grant equivalent to 'user'@'%' ?
23:53 beneggett joined #salt
23:54 hal58th http://docs.saltstack.com/en/latest/ref/states/all/salt.states.mysql_grants.html
23:55 rojem joined #salt
23:55 dergrunepunkt seen that but no mention to add something like a any host wildcard
23:55 alexr__ joined #salt
23:55 hal58th Try host: % or *
23:56 dergrunepunkt done that too, also %%
23:56 dergrunepunkt but jinja complains
23:56 dergrunepunkt maybe escaping the "%"?

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