Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2017-01-31

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

All times shown according to UTC.

Time Nick Message
00:02 danlsgiga left #salt
00:08 eThaD joined #salt
00:13 cro joined #salt
00:14 mirceaulinic joined #salt
00:16 Aleks3Y joined #salt
00:21 justanotheruser joined #salt
00:26 bookwar joined #salt
00:28 abednarik joined #salt
00:32 hacks joined #salt
00:42 jagguli hi, I've just written my own custom beacon, but I cant seem to get it to fire
00:43 jagguli i've restarted the master and ran salt minion saltutils.refresh_beacons
00:49 eThaD joined #salt
00:51 bookwar joined #salt
00:54 SaucyElf joined #salt
01:04 Neighbour joined #salt
01:11 eThaD joined #salt
01:15 nZac joined #salt
01:17 onlyanegg joined #salt
01:24 onlyanegg Hello, I'm having trouble with the boto_elb module. I have boto3 installed, but I get this error: Module function boto_elb.deregister_instances is not available
01:25 onlyanegg https://gist.github.com/onlyanegg/e83e0b3c108d23e6b20992c8b3207798
01:27 cyborg-one joined #salt
01:44 whytewolf onlyanegg: :depends: boto >= 2.33.0
01:46 onlyanegg yeah, I saw that.
01:46 whytewolf boto3 != boto
01:46 onlyanegg oh, hmm. ok thanks
01:46 onlyanegg I guess I thought boto3 was like boto v3
01:46 whytewolf it kind of is. but boto and boto3 are very different libraries
01:47 whytewolf which is why the 3 is pegged on the end of boto3
01:48 onlyanegg ok, thx!
01:50 mavhq joined #salt
01:53 eThaD joined #salt
01:55 doorsnsardines joined #salt
01:58 ALLmightySPIFF joined #salt
02:00 doorsnsardines Hi everyone, I've got a question about what is expected behavior for dictionary merging in pillars. The docs I've been referencing (https://docs.saltstack.com/en/latest/topics/pillar/#pillar-dictionary-merging) suggest that multiple key-value pairs inherited from different pillar sls files would be merged to create one pillar structure with the data from both files, but I'm actually seeing the 2nd file declared in the top.sls replace the 1st. A demonstr
02:04 doorsnsardines I'm just trying to figure out if the way I have my pillars laid out is the problem here, or if these pillar files should be merging and aren't
02:05 Tanta when you merge, 2 becomes 1
02:05 justan0theruser joined #salt
02:05 Tanta if there is a key collision I believe the last instance of that key takes over
02:05 doorsnsardines right, but there isn't a key collision here
02:05 whytewolf https://docs.saltstack.com/en/latest/ref/configuration/master.html#pillar-merging-options
02:06 guerby joined #salt
02:06 whytewolf if something is overrighting something else. you have a key collision somewhere in the tree
02:08 Tanta you can also include pillar files from pillar files
02:08 doorsnsardines actually, from that link it looks like the merging is working fine for dicts, but the default action for lists appears to be not to merge them
02:08 doorsnsardines so maybe that's what I need to change here
02:09 doorsnsardines would that pillar_merge_lists bool just be set in the pillar top.sls?
02:09 whytewolf no, that is a master config option
02:10 whytewolf everything in that list is master config options
02:11 doorsnsardines yup, setting that fixes everything
02:14 guerby joined #salt
02:15 doorsnsardines cool, so my pillar files are right, and I just need to change expected behavior. That's an easy enough fix
02:17 catpiggest joined #salt
02:19 tercenya joined #salt
02:26 Bluebell_ joined #salt
02:27 guerby joined #salt
02:27 dyasny joined #salt
02:33 cryptolukas joined #salt
02:33 evle2 joined #salt
02:34 eThaD joined #salt
02:52 djgerm https://github.com/saltstack/salt-contrib/blob/master/grains/ec2_tags.py mentions placing the py in "<salt_root>/_grains"
02:52 djgerm what does that mean!?
02:53 whytewolf ...
02:53 whytewolf it meas that so the file is accessable by salt://_grains/ec2_tags.py
02:53 djgerm oh you're blowing my mind
02:53 whytewolf where ever your file_dir is pointed
02:54 djgerm file_roots?
02:54 whytewolf on your master
02:54 whytewolf [or minion]
02:55 whytewolf how you tell salt where the states are located
02:55 djgerm ah ok. gitfs
02:56 eThaD joined #salt
02:57 djgerm it's a bizarre phrasing right? "salt_root" isn't something generally thrown around from my observations here :)
02:58 whytewolf not that bizarre. we throw root around a lot
02:58 whytewolf normally meaning pretty much the exact thing
02:58 djgerm can those instructions be applied to this too? https://github.com/saltstack/salt-contrib/blob/master/grains/ec2_info.py
02:59 whytewolf yes... thats a typically custom grain
03:05 djgerm first custom grains ^_^
03:21 djgerm worked like a charm!
03:21 djgerm thanks whytewolf
03:22 gableroux joined #salt
03:25 djgerm it really only took 4 minutes too.
03:37 eThaD joined #salt
03:46 djgerm so if I wanted a state that takes grains from multiple other minions to populate some variables, what's the best way to do that?
04:08 whytewolf grains from other minions? that would be the salt mine
04:08 Bluebell_ left #salt
04:41 nZac joined #salt
05:11 preludedrew joined #salt
05:19 samodid joined #salt
05:20 eThaD joined #salt
05:35 rdas joined #salt
05:38 bocaneri joined #salt
05:46 barmaley joined #salt
05:55 rdas joined #salt
06:08 netcho joined #salt
06:10 evidence joined #salt
06:21 netcho_ joined #salt
06:28 onlyanegg joined #salt
06:32 ivanjaros joined #salt
06:33 rdas joined #salt
06:36 eseyman joined #salt
06:42 nZac joined #salt
07:00 sh123124213 joined #salt
07:15 netcho_ joined #salt
07:17 impi joined #salt
07:28 krymzon joined #salt
07:49 onlyanegg joined #salt
07:55 Rumbles joined #salt
07:56 aw110f joined #salt
07:59 aw110f_ joined #salt
08:00 yuhl___ joined #salt
08:05 samodid joined #salt
08:08 catpig joined #salt
08:15 jason` joined #salt
08:16 usernkey joined #salt
08:20 o1e9 joined #salt
08:22 ReV013 joined #salt
08:29 LondonAppDev joined #salt
08:43 coredumb joined #salt
08:43 coredumb Morning folks
08:44 coredumb is there a way in jinja to match if minion is in a nodegroup? like %{ if grain['hostname'] is in NodeGroup }% or something like that ?
08:46 JohnnyRun joined #salt
08:50 onlyanegg joined #salt
09:03 mikecmpbll joined #salt
09:04 krymzon joined #salt
09:05 eThaD joined #salt
09:05 toanju joined #salt
09:07 Hybrid joined #salt
09:12 clarizen joined #salt
09:13 LondonAppDev joined #salt
09:18 clarizen hello, we are having problem running states on windows servers 2008 R2. PS 5, microsoft visual c++ redistributable, .net 4.6 are installed.
09:19 babilen coredumb: Not aware of it, but you might just solve that problem in top.sls with appropriate targeting
09:19 coredumb babilen: just found https://docs.saltstack.com/en/latest/topics/targeting/nodegroups.html#using-nodegroups-in-sls-files
09:20 clarizen we are getting Data failed to compile: Jinja variable str object has no element 0 - for any state, even a state we know is working properly for linux
09:20 coredumb babilen: actually I wanted that to be able to modify top.sls
09:20 gettup joined #salt
09:20 babilen coredumb: Good find! :)
09:21 babilen clarizen: Same minion/master versions everywhere?
09:23 clarizen version 2016.11.1 on master and minions. we are upgrading to 2016.11.2 at the moment to see if it helps
09:23 Rumbles joined #salt
09:23 trib joined #salt
09:25 yuhl___ left #salt
09:26 clarizen any ideas?
09:26 babilen I (luckily) don't have to touch Windows at all, but most of the time I saw that error it was due to a version mismatch (data structures changed between versions and are accessed differently)
09:26 babilen To actually help we would, I guess, have to see the actual error and state on a pastebin such as http://paste.debian.net, https://gist.github.com, http://sprunge.us, …
09:27 trib hello. hope you are all well. i have a question regarding salt-cloud. i am trying to setup an ec2 machine with multiple security groups. i have tried many think with no success. according to the docs (https://docs.saltstack.com/en/latest/topics/cloud/aws.html)  i should use "securitygroupname:". this results in nontype has no attribute add. any information would be appreciated on this issue.
09:28 eThaD joined #salt
09:30 lasseknudsen joined #salt
09:32 jhauser joined #salt
09:32 s_kunk joined #salt
09:33 clarizen I copied the relevant error here. the rest of the errors seems irrelevant as it's the same template seen in other errors.. The problem seems to be the minion fails to compile the states. any state.
09:33 clarizen my state supposed to install iis on windows server. while the state fails to compile, the salt install iis command line works fine.
09:34 Rkp_ trib: I dunno, so far I used   securitygroupid:
09:35 bookwar joined #salt
09:35 Rkp_ with stuff like    - sg-6g6f0ba3
09:38 trib @Rkp_ i have tried that... let me give it another go
09:40 trib @Rkp_, perfect... that works. i assume the docs are "mistaken" :) that you for the assistance.
09:41 babilen clarizen: Where did you copy the error?
09:42 clarizen babilen: Data failed to compile: Jinja variable str object has no element 0
09:42 babilen That doesn't even allow me to figure out in which module or on which line the exception was raised
09:43 clarizen Data failed to compile:  Pillar failed to render with the following messages: Rendering Primary Top file failed, render error: Jinja variable str object has no element 0
09:43 clarizen This is the full error
09:43 yuhl___ joined #salt
09:43 babilen So, its your pillar rather than the state .. Anything suspicious in there?
09:44 nZac joined #salt
09:46 clarizen we didn't configure any relevant pillar for it specifically. But i'll check all the pillars we have to see if there is something weird. thanks!
09:49 netcho joined #salt
09:51 babilen clarizen: You can trigger pillar rendering with "saltutil.refresh_pillar" and you might find more detailed information in the master log
09:53 clarizen babilen: I'm new to salt (as you may have noticed ;) ) - so thanks for your help and patience :)
09:53 clarizen will try that
10:00 babilen clarizen: That's absolutely no problem :)
10:08 impi joined #salt
10:14 netcho joined #salt
10:17 nickabbey joined #salt
10:19 clarizen babilen: We had a problem with our grains apparently. problem solved! thanks for the help! :)
10:25 scristian joined #salt
10:29 eThaD joined #salt
10:30 abednarik joined #salt
10:35 coredumb babilen: now makes me wonder how exactly I should ensure nothing secret gets shared with the minions :O
10:50 cacasmacas joined #salt
10:50 onlyanegg joined #salt
10:51 lmr joined #salt
10:55 netcho joined #salt
10:57 amcorreia joined #salt
11:05 barmaley test
11:06 jagguli tested
11:08 barmaley joined #salt
11:08 jeffspeff joined #salt
11:10 eThaD joined #salt
11:10 barmaley left #salt
11:12 barmaley joined #salt
11:12 barmaley left #salt
11:12 aarontc joined #salt
11:17 barmaley joined #salt
11:19 barmaley left #salt
11:21 barmaley joined #salt
11:25 barmaley joined #salt
11:25 barmaley joined #salt
11:27 tedski joined #salt
11:28 barmaley joined #salt
11:30 netcho_ joined #salt
11:38 byteriot joined #salt
11:43 usernkey joined #salt
11:43 barmaley joined #salt
11:46 barmaley joined #salt
11:47 ravi____ joined #salt
11:55 cryptolukas joined #salt
12:05 teclator joined #salt
12:05 amcorreia joined #salt
12:12 babilen coredumb: grains and secrets are not a good combination .. Could you elaborate a little? (off for lunch soonish though)
12:21 coredumb babilen: we talk about master pillars here :)
12:22 coredumb all your master's config get's added to the minion as a pillar
12:22 coredumb so any "secret" in your master configuration could be accessed from a minion
12:26 babilen Oh yeah, I noticed that in the documentation and thought "Well, that rules out this solution in some cases"
12:26 babilen So, lunch now
12:28 coredumb have a good lunch :)
12:32 ssplatt joined #salt
12:34 impi joined #salt
12:39 overyander joined #salt
12:41 rdas joined #salt
12:46 coredumb are there any grains that are non overwritable from states ?
12:47 coredumb I'd feel itchy if a state could change it's grain.id ...
12:47 coredumb This state allows for grains to be set. Grains set or altered this way are stored in the 'grains' file on the minions, by default at: /etc/salt/grains
12:47 coredumb Note: This does NOT override any grains set in the minion file.
12:47 coredumb I'm a bit puzzled by that
12:47 coredumb how would that play ?
12:48 coredumb if grain.id is enforced in the minion file then it will not be overriden ?
12:48 coredumb but if it's written in /etc/salt/grains, after a minion restart which one gets precedence?
12:51 onlyanegg joined #salt
12:53 _Cyclone_ joined #salt
12:53 coredumb yep works as they say
12:54 overyander ?
12:55 coredumb grains set in /etc/salt/grains don't override the ones set in minion config file
12:57 Tanta joined #salt
13:01 overyander coredumb just to add to your information, read the comment on https://github.com/saltstack/salt/blob/develop/salt/grains/core.py
13:02 Tanta joined #salt
13:05 krymzon joined #salt
13:05 kettlewell joined #salt
13:15 coredumb overyander: ok
13:22 raspado joined #salt
13:24 netcho_ joined #salt
13:27 numkem joined #salt
13:29 ravenx joined #salt
13:29 ravenx hey guys, i managed to set up pillar roles, with a dev and a staging using /srv/pillars.
13:29 ravenx however, now i'm sorta confused as to where to put my actual k:v pairs that's needed to fill in my configuration template
13:30 edrocks joined #salt
13:34 ravenx here is the structure of my dir: https://paste.debian.net/911876/
13:34 raspado joined #salt
13:34 netcho joined #salt
13:35 amagawdd joined #salt
13:47 hlub joined #salt
13:55 babilen ravenx: In dev.sls and stag.sls for example
13:55 babilen (or any other semantic organisation that makes sense)
13:57 ssplatt joined #salt
13:59 jas02_ joined #salt
14:00 Firewalll joined #salt
14:02 ravenx aaah
14:02 ravenx so i can continue it there
14:06 ravenx babilen: it worked.  thanks babilen.
14:17 gladia2r joined #salt
14:19 eThaD joined #salt
14:23 eThaD joined #salt
14:28 xet7 joined #salt
14:42 coredumb folks
14:43 coredumb I fail to grasp how I can prevent a minion to be forbidden to exec a saltenv
14:43 coredumb Is there a way that I overlooked or should I start patching salt myself ?
14:44 AndreasLutro good luck with that
14:44 AndreasLutro probably just another reason not to use salt envs
14:44 nickabbey joined #salt
14:44 ALLmightySPIFF joined #salt
14:45 fooker joined #salt
14:45 coredumb AndreasLutro: that's the only way I found to limit the reach of what's in salt:// per nodegroup
14:45 coredumb if you got a better idea I'm all ears
14:45 AndreasLutro why do you need to limit? sensitive data?
14:46 AndreasLutro put it in pillars instead
14:47 coredumb AndreasLutro: not sensitive per se
14:47 esharpmajor joined #salt
14:47 coredumb I don't trust the people that write states and need to ensure they can't fetch files/exec states from someone else where they shouldn't
14:48 ssplatt make different file roots for different envs?
14:48 ssplatt then don’t assign that linode to the enfg
14:48 ssplatt env
14:48 ssplatt er minion. not linode
14:48 AndreasLutro coredumb: then don't give those people direct access to salt, write wrapper scripts or a web interface or whatever
14:49 AndreasLutro salt comes with very few safeguards like that
14:49 coredumb ssplatt: well thing is nothing preventing you to issue state.apply saltenv=another_env
14:49 vj4 joined #salt
14:49 ssplatt don’t let admins on who do dumb things like that/
14:50 coredumb ssplatt: well worse it can be called directly from the state files
14:51 coredumb AndreasLutro: I need to let people I don't trust write their own states
14:51 AndreasLutro maybe don't use salt for this particular thing then, right tool for the job etc
14:52 coredumb it's gonna be fine 99.9% of the time with the setup I have but .... I need to prevent this specific attack vector. That's pretty much the only one I can't find a way around without patching
14:52 onlyanegg joined #salt
14:52 mpanetta joined #salt
14:53 AndreasLutro I don't think you're going to get far by patching either tbh, running states etc is such a core part of salt
14:53 ssplatt coredumb: i think you need to get your users to write formulas and do code review via git
14:53 coredumb yep bothers me
14:54 ssplatt sounds like you have a process issue
14:54 coredumb I may
14:54 coredumb but doing code reviews is too much work
14:55 ssplatt maybe at first but once you’ve got your formula library going all the changes are minimal and readily apparent if people are doing bad thigns
14:55 netcho joined #salt
14:55 mpanetta joined #salt
14:56 coredumb yeah but I'll have couple 10s of different formulas with that ...
14:56 dendazen joined #salt
14:56 coredumb maybe a hundred easily
14:58 ssplatt i think we have upwards of 50 at the moment
14:58 ssplatt theres a bunch in github/saltstack-formulas
14:58 ssplatt but we made our own because we didn’t like how there was no similarity between them
14:58 ssplatt they’re pretty easy to make
14:59 ssplatt start with minimum viabilty for a single use case.  then someone can PR when they need to add more functionality
15:02 racooper joined #salt
15:04 coredumb ssplatt: I'll dig that
15:04 lord2y joined #salt
15:07 nZac joined #salt
15:07 ravenx is it possible to use salt-api without any authentication, like pam
15:08 ravenx no external_auth too
15:15 beardedeagle joined #salt
15:15 ksk ravenx: might be an option to use a reverse proxy and make it authenticate users? (im not into salt-api at all)
15:15 beardedeagle Dumb question: can you use the gpg renderer in masterless setups?
15:18 sarcasticadmin joined #salt
15:20 keltim joined #salt
15:33 edrocks joined #salt
15:33 mikecmpbll joined #salt
15:35 PatrolDoom joined #salt
15:35 barmaley joined #salt
15:38 bantone joined #salt
15:38 eThaD joined #salt
15:39 barmaley joined #salt
15:43 edrocks if your using dockerng.image_present in the same sls file as a dockerng.running is there a requisite to make sure the image_present is run first?
15:43 edrocks ie before updating the container
15:46 dynamicudpate joined #salt
15:48 eThaD joined #salt
15:50 edrocks never mind, this explains it pretty well https://docs.saltstack.com/en/latest/ref/states/requisites.html
15:57 _JZ_ joined #salt
15:59 onlyanegg joined #salt
16:02 joshin joined #salt
16:02 joshin joined #salt
16:03 Aleks3Y joined #salt
16:07 boredatwork joined #salt
16:07 danbishop joined #salt
16:07 danbishop Hi All :)
16:08 danbishop I wonder if anyone might be able to help me with something... I'm new to Salt, so this might be obvious... but try as I might I can't find anything in the tops or any kind of forum...
16:09 danbishop I have a config file managed by Salt for a service... but I need to stop that service if ever the config file changes, then restart it.
16:09 hexa- you have a state that installs it
16:09 danbishop watch and onchanges are no good as they appear to be applied after the file has been written
16:09 hexa- like
16:09 hexa- service:
16:09 hexa- pkg.installed
16:09 hexa- extend it with service.running
16:09 rlatimore joined #salt
16:09 hexa- service.running:
16:10 hexa- - enable: True
16:10 hexa- - watch:
16:10 hexa- - file.managed: yourotherstate
16:10 danbishop thanks hexa, the problem with that approach, is that salt writes the file then restarts the service...
16:10 danbishop I need to stop the service, write the file, start the service
16:11 hexa- https://docs.saltstack.com/en/latest/ref/states/all/salt.states.service.html#salt.states.service.running
16:11 hexa- interesting
16:11 Rkp_ what happens if you change the file without the service being stopped?
16:11 hexa- inconsistency probably?
16:11 danbishop when the service stops, it then rewrites the file
16:11 danbishop exactly
16:12 danbishop so salts changes are overwritten with the old initial version
16:12 wendall911 joined #salt
16:13 Sketch you could just use ordered states.  service.dead: - order: 1 ... file.managed: - order: 2 ... service.running: - order: 3
16:13 hexa- you, or require the service to be stopped in the file.managed state
16:13 danbishop won't that stop the service every time though, regardless of whether the file has changed or not?
16:13 Sketch danbishop: yeah
16:14 Sketch hexa's idea is probably better
16:14 danbishop How would I implement hexa's idea sorry? :/
16:14 Sketch the service.running can always happen on it's own (just make sure it's after the file.managed)
16:15 dendazen joined #salt
16:15 lompik joined #salt
16:15 nixjdm joined #salt
16:16 danbishop I have the service.running after the file.managed and that brings it back up ok, but I can't get it to stop the service ONLY if there's a change to the file
16:16 onlyanegg joined #salt
16:18 Sketch i think you could do service.dead: - onchanges; - file: your_file.managaed_staate
16:18 Rkp_ it's going to be a tricky one because it doesn't fit the usual workflow of salt changes to services
16:18 beardedeagle joined #salt
16:18 danbishop sketch: unfortunately, onchanges runs after whatever has changed it would appear... so that works, but it writes the file and then stops the service
16:19 Sketch ah, i see
16:19 danbishop and when this particular service stops... it re-writes its current in memory config to the conf file
16:19 danbishop overwriting the changes salt has just made
16:19 Sketch hacky workaround: do file.managed again after the service.dead
16:20 Rkp_ as an ugly solution you could write the file twice, and chain them with requires / onchanges
16:20 danbishop ahhhhhh
16:20 Sketch you wouldn't even need a require/onchanges on the second one
16:20 Rkp_ although I can't remember trying to manage the same file with two file.managed states
16:20 Rkp_ so I'm not sure if that would work
16:20 danbishop that's an interesting workaround, thanks guys! :D
16:20 Rkp_ there's probably a more elegant solution but...
16:20 danbishop I'll give it a go
16:21 danbishop Yeh, I was hoping to find something elegant, but at least this is something that works... which is better than my current situation
16:22 verdurin joined #salt
16:22 teclator joined #salt
16:24 rburkholder joined #salt
16:25 danbishop Hah! It worked!!!
16:25 danbishop Thank you :)
16:34 _beardedeagle joined #salt
16:35 nickabbey joined #salt
16:36 Rkp_ good to hear! that might even be the least ugly solution
16:41 mikecmpbll joined #salt
16:41 debian112 joined #salt
16:44 eThaD joined #salt
16:49 WesleyTech joined #salt
16:52 spiette joined #salt
16:57 Brew joined #salt
16:57 cryptolukas joined #salt
16:58 impi joined #salt
17:01 Edgan joined #salt
17:02 netcho joined #salt
17:12 WesleyTech_ joined #salt
17:26 eThaD joined #salt
17:27 MTecknology It's kinda fun when you get a salt master working so gard the gpg agent is holding up a full core
17:28 MTecknology err.. three gpg agents each at 100% cpu - that might be a better way to phrase what I meant to say
17:37 ALLmightySPIFF joined #salt
17:39 leonkatz joined #salt
17:41 nickabbey joined #salt
17:41 leonkatz Any one had issues with having tags in boto_secgroup.present: ?
17:42 leonkatz I'm gettingAttributeError: 'SecurityGroup' object has no attribute 'add_tags'
17:47 CeBe joined #salt
17:50 jeffspeff does salt cache minion grains or installed packages anywhere?
17:50 sh123124213 joined #salt
17:52 whytewolf grains, yes. installed packages, no.
17:54 whytewolf leonkatz: what version are you using. and is from the exacution module or from a state module?
17:55 leonkatz salt 2016.11.1 (Carbon), from the state
17:56 whytewolf leonkatz: please post your state then.
17:56 whytewolf to gist
17:56 whytewolf or other pastebin like service
17:56 leonkatz create product security group:
17:56 leonkatz boto_secgroup.present:
17:56 leonkatz - name: {{ security_group }}
17:56 leonkatz - description: {{ description }}
17:56 leonkatz - vpc_id: {{ vpc }}
17:56 leonkatz - profile:
17:56 leonkatz keyid: {{ key_id }}
17:56 leonkatz key: {{ key }}
17:56 leonkatz region: {{ region }}
17:56 leonkatz - tags:
17:56 leonkatz name: {{ security_group }}
17:57 whytewolf NOT HERE!
17:57 ssplatt pastie, gist....
17:57 leonkatz sorry
17:57 edrocks joined #salt
17:57 leonkatz can i delete
17:57 whytewolf no
17:59 whytewolf what version of boto do you have installed?
17:59 Ahlee this is awesome. vcenter is finding LIBEAY32.dll and SSLEAY32.dll and bombing out
17:59 Ahlee from our salt install, that is
18:00 leonkatz i'm not sure how to get that version
18:00 whytewolf leonkatz: how did you install boto?
18:00 leonkatz apt-get
18:00 nickabbey joined #salt
18:01 leonkatz 2.20.1-2ubuntu2
18:01 leonkatz thanks
18:03 ivanjaros3916 joined #salt
18:07 whytewolf leonkatz: you might need to post this to the issues.. i don't see any reason it shouldn't work. unless boto doesn't have the add_tags function. which it should
18:07 eThaD joined #salt
18:07 tvinson leonkatz: anecdotally, i had a lot of issues with boto when there was any slowness with the amazon api. i hacked it up a little with the retry decorator as an ugly workaround. it's been a while since i've looked at any of that though.
18:11 tvinson it sounds a little like this, the api returns immediately but it's a few seconds before the security group actually exists. I bet that SecurityGroup object is None if you do something to inspect it.
18:12 lumtnman joined #salt
18:12 drawsmcgraw gtmanfred: Would you happen to know anything about this stacktrace I'm seeing with the Nova driver in the latest Salt (2016.11.2)? http://dpaste.com/3KATE2D
18:13 gtmanfred shit
18:13 gtmanfred set use_keystoneauth: false in /etc/salt/cloud
18:14 drawsmcgraw gtmanfred: can I put it in with the provider config or does it need to be at the 'global' level?
18:14 drawsmcgraw Also -> Would you like me to open an issue with the details of what I'm seeing? :)
18:15 gtmanfred it can go in either
18:15 drawsmcgraw Yes. Yes, I can put it into the provider config.
18:15 drawsmcgraw cool, thanks.
18:16 gtmanfred drawsmcgraw: https://github.com/saltstack/salt/pull/39079
18:16 saltstackbot [#39079][OPEN] use_keystoneauth should default to False if not specified | Tests written?...
18:17 drawsmcgraw "gtmanfred committed 2 minutes ago " <-- holy crap that was fast!
18:17 drawsmcgraw thanks gtmanfred !
18:17 SaucyElf joined #salt
18:18 SaucyElf joined #salt
18:19 WesleyTech_ joined #salt
18:20 amagawdd joined #salt
18:24 aw110f joined #salt
18:29 eThaD joined #salt
18:29 lumtnman joined #salt
18:34 Inveracity joined #salt
18:38 ryan8403 joined #salt
18:40 tmkerr joined #salt
18:42 catpig joined #salt
18:43 lord2y joined #salt
18:43 tmkerr I've created a new salt formula. Can anyone help me add? It's on my github ready to go
18:44 leonkatz #whytewolf based on what you said i uninstalled python-boto used pip to install the latest and that seems to have fixed my issue
18:45 whytewolf tmkerr: post a quick write up about it to the salt users group. include your github repo link.
18:45 whytewolf leonkatz: kewl
18:45 s_kunk joined #salt
18:52 mavhq joined #salt
18:57 sp0097 joined #salt
18:57 ssplatt …  INFO: Running version: 2017.01.10 …
18:57 ssplatt nice.
18:58 ssplatt oh i guess that’s just bootstrap
19:00 ChubYann joined #salt
19:03 Praematura joined #salt
19:03 babilen It would be, yes :)
19:07 babilen Sometimes you just step back, watch multiple interconnected services and boxes being bootstrapped and can't help yourself but think: This is so great!
19:08 babilen Forgotten are all the hours in which you honed mine function aliases, custom grains and SLS files ..
19:08 babilen This is not the time to think of work, but time to behold the magic :)
19:10 eThaD joined #salt
19:13 edrocks joined #salt
19:14 mpanetta joined #salt
19:20 mpanetta joined #salt
19:20 cmarzullo indeed. it's a beatiful thing when it just works.
19:21 cmarzullo then someone comes up with a new hostname scheme and everything breaks.
19:26 lumtnman joined #salt
19:30 spectorfreak joined #salt
19:32 eThaD joined #salt
19:35 bigjazzsound joined #salt
19:36 aboe joined #salt
19:39 tercenya joined #salt
19:41 nickabbey joined #salt
19:43 pvz joined #salt
19:44 cryptolukas joined #salt
19:44 cmarzullo can you refresh grains when running a state? Like I have a state to set the host name. but the hostname grain doesn't update.
19:45 whytewolf cmarzullo: if you are checking the hostname grain through jinja a state won't change it because the state runs after jinja
19:45 cmarzullo hmmmm. yes indeed.
19:46 babilen cmarzullo: reload_grains: True
19:47 babilen https://docs.saltstack.com/en/latest/ref/states/requisites.html#reload -- but see whytewolf's comment
19:47 cmarzullo But I'm thinking what whytewolf saying. It won't update the jinja.
19:49 Sketch aha, that explains why i couldn't have osrelease update when updating my OS release during a salt run
19:53 fooker hi, im seeking for help with a somewhat strange usecase:
19:53 fooker I'm looking for a way to have a minion running masterless but let it publish informations to a master
19:54 fooker the reason for this is: We manage a couple of systems with a relatively loose group of administrators
19:55 Sketch whytewolf: does that apply to included states, or would those be processed separately?
19:55 fooker each of these admins have full access to all systems. but for one system we need to protect personal data
19:55 Sketch i think the include is done before the run, so it probably does
19:55 pierB joined #salt
19:55 fooker and only allow a bunch of people acces to the system
19:55 fooker is there any experience with such a setup?
19:56 whytewolf Sketch: i would think it would apply as the includes are done as part of building out the lowstate. which is still done before the states are run
19:57 whytewolf fooker: you want to look into returners... and instead of returning to a master you could have them return to almost any kind of system that you can link into allowing for some nicer ways of tracking things
19:58 whytewolf fooker: https://docs.saltstack.com/en/latest/ref/returners/
20:00 whytewolf Sketch: iirc the only jinja rendered after states is the file template jinja.
20:00 toanju joined #salt
20:00 fooker whytewolf: maybe publishing is the wrong word for what I'm looking for. I.e. we're using mine to collect ssh host keys from all systems and use them to provision known_hosts
20:01 beardedeagle joined #salt
20:01 whytewolf ahh, mine won't work because of being masterless ....
20:02 fooker i found the use_master_when_local option but I really can'T figure out what it's doing
20:03 leonkatz Is there a way to add a rule to an existing security group in AWS without removing existing security groups?
20:03 leonkatz sorry that should say security group rules
20:04 leonkatz Is there a way to add a rule to an existing security group in AWS without removing existing security groups rules?
20:04 pvz hey all, i'm seeing salt leave tons of files in `/tmp/tmp*` up to 600k on one of the instances. Has anyone seen this before?
20:05 whytewolf pvz: are you using salt-ssh?
20:06 whytewolf the files in tmp should be cleaned up unless you told salt not to
20:06 pvz nope although i do only see this on 4.2.4 and not 4.1.8 but could be un related
20:07 whytewolf fooker: https://github.com/saltstack/salt/issues/16215
20:07 saltstackbot [#16215][MERGED] Local files + remote execution very difficult | 'file_client: local' immediately disables connections to a master. salt-call --local not only sets 'file_client: local', but also disables any event sending. I'm deploying my salt files, but would also like remote execution via master/minion. I'd like to use the event system and such as well....
20:13 pvz https://github.com/saltstack/salt/issues/37541 that would do it
20:13 saltstackbot [#37541][MERGED] salt-minion does not clean up temp files for templates | Description of Issue/Question...
20:13 eThaD joined #salt
20:14 snarfy^ joined #salt
20:20 beardedeagle joined #salt
20:22 honestly EvaSDK: I've been sick, but I didn't forget your salt-formulas PR
20:26 nickabbey joined #salt
20:27 EvaSDK honestly: oh good, I was pondering whether to send a ping or not :-)
20:27 lindleyw joined #salt
20:27 lindleyw Hi, is there a way to run a mysql.sls command as sudo?
20:28 lindleyw For some reason, I'm getting a fail to auth error with salt even though the root credentials are blank password
20:29 lindleyw but when I got to the box itself and try to run the connect `sudo mysql -u root -p` it works
20:34 DammitJim joined #salt
20:34 krymzon joined #salt
20:35 eThaD joined #salt
20:37 tracphil joined #salt
20:37 kojiro joined #salt
20:44 babilen lindleyw: You might want to use https://docs.saltstack.com/en/latest/ref/states/all/salt.states.mysql_query.html
20:44 babilen (note https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.mysql.html#module-salt.modules.mysql )
20:45 Sketch lindleyw: -p specifies that you are entering a password manually...
20:45 sjorge joined #salt
20:45 Sketch are you specifying a user/password in salt?
20:46 lindleyw I'm specifying a blank password
20:47 Sketch ah.  not sure how salt handles that...(or mysql for that matter)
20:47 Sketch if there's a difference between blank password and no password
20:47 lindleyw yeah, it's kind of weird
20:47 Sketch have you considered setting it to something more sensible? ;)
20:48 lindleyw Well I did that before, I set it with mysql_secure_installation, then I had the same problem
20:48 lindleyw even if I specified a password I just set
20:51 lumtnman joined #salt
20:51 kettlewell joined #salt
20:53 lumtnman joined #salt
20:56 lumtnman joined #salt
20:59 xbglowx_ joined #salt
21:00 whytewolf lindleyw: HOW are you telling salt the password? also. iirc blank passwords are not supported. also to your original question. salt doesn't connect to mysql through a terminal so sudo would be worthless.
21:01 lindleyw right, I'm seeing that now, it's using pymysql
21:09 leonkatz joined #salt
21:16 eThaD joined #salt
21:28 cwright joined #salt
21:32 brokensyntax joined #salt
21:38 eThaD joined #salt
21:51 Rumbles joined #salt
21:54 mikecmpbll joined #salt
21:56 jschoolcraft joined #salt
22:01 SaucyElf joined #salt
22:03 SaucyElf_ joined #salt
22:16 beardedeagle joined #salt
22:19 eThaD joined #salt
22:21 esharpmajor joined #salt
22:22 jeblair joined #salt
22:40 mpanetta joined #salt
22:41 xbglowx_ joined #salt
22:52 mavhq joined #salt
22:53 evidence joined #salt
22:57 keldwud joined #salt
22:58 keldwud is there a benefit or reason to use "salt '<target>' state.sls <state>" over "salt '<target>' state.apply <state>"? What are the differences between the two? I have been using state.apply and prefer that method but am curious as to whether I should be doing it differently
23:00 whiteinge state.apply just wraps state.sls and state.highstate. no functional difference between them.
23:02 keldwud is there a 'best practice'? for example, would I want to be in the habit of not checking my high states when applying states? or would I want to always be checking my high states when I apply new states?
23:05 edrocks joined #salt
23:25 PatrolDoom joined #salt
23:25 dendazen joined #salt
23:39 xet7 joined #salt
23:39 xbglowx joined #salt
23:42 prg3 joined #salt
23:42 PatrolDoom joined #salt

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