Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2014-06-16

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

All times shown according to UTC.

Time Nick Message
00:04 joehillen joined #salt
00:16 Teknix joined #salt
00:20 n8n joined #salt
00:27 dccc joined #salt
00:30 diegows joined #salt
00:33 elfixit joined #salt
00:33 flebel joined #salt
00:37 Teknix joined #salt
00:46 Teknix joined #salt
01:04 Ryan_Lane joined #salt
01:19 mgw joined #salt
01:33 thayne joined #salt
01:35 krow joined #salt
01:40 ajw0100 joined #salt
02:02 gregdek joined #salt
02:12 gregdek left #salt
02:19 cachedout joined #salt
02:26 schimmy joined #salt
02:35 mateoconfeugo joined #salt
02:36 jalaziz joined #salt
02:38 ajw0100 joined #salt
02:43 acabrera joined #salt
02:43 mgw joined #salt
02:49 XenophonF joined #salt
02:51 wigit joined #salt
02:58 bhosmer joined #salt
03:13 mateoconfeugo joined #salt
03:18 catpigger joined #salt
03:20 diegows joined #salt
03:23 jalaziz joined #salt
03:43 garthk joined #salt
03:46 XenophonF joined #salt
03:53 ipalreadytaken joined #salt
03:54 malinoff joined #salt
04:00 otter768 joined #salt
04:01 stotch joined #salt
04:02 mateoconfeugo joined #salt
04:03 TyrfingMjolnir joined #salt
04:04 melinath joined #salt
04:04 ajolo_ joined #salt
04:08 seventy3_away joined #salt
04:09 ipalreadytaken joined #salt
04:33 TheThing joined #salt
04:44 Pimpdamap joined #salt
04:44 Pimpdamap http://trrlewis.blogspot.com/
04:44 Pimpdamap left #salt
04:44 Nexpro1 joined #salt
04:53 gywang joined #salt
04:53 ramteid joined #salt
04:55 gywang Hi, I got error msg like "State pkg.installed found in sls xxx is unavailable" , any suggestion?
04:58 malinoff gywang, what OS do you have on your minion?
05:00 felskrone joined #salt
05:02 TheThing joined #salt
05:03 gywang redhat 5.7
05:04 malinoff gywang, and salt version is..?
05:04 gywang 2014.1.5
05:05 malinoff gywang, do you have SELinux enabled?
05:08 gywang SELINUX=disabled
05:08 gywang should I enable SELINUX ?
05:09 malinoff gywang, no, you shouldn't
05:11 malinoff I remember such problems with old yum module in conjunction with SELinux
05:11 ajolo_ joined #salt
05:11 gywang Then how can I find where the problem is
05:11 malinoff If you have ssh access to the minion, you can try to run salt-call state.sls yourstate -l debug
05:11 malinoff locally, I mean
05:12 gywang [INFO    ] Running state [sed] at time 13:12:39.169373 [ERROR   ] State pkg.installed found in sls app_server.check is unavailable
05:13 gywang no other error msg
05:13 malinoff gywang, could you paste your state file?
05:14 gywang sed:
05:14 gywang pkg.installed:
05:14 gywang - name: sed
05:14 gywang the simplest state file
05:14 malinoff No, in http://pastie.org
05:16 gywang http://pastie.org/9293765
05:17 gywang http://pastie.org/9293766
05:19 malinoff gywang, https://github.com/saltstack/salt/blob/v2014.1.5/salt/modules/yumpkg.py#L45-L61 this is why you may not have pkg module - please, check all the conditions
05:20 krow joined #salt
05:25 JeroenH_ joined #salt
05:26 jhauser joined #salt
05:28 kermit joined #salt
05:30 danelip joined #salt
05:33 ipalreadytaken joined #salt
05:34 krow joined #salt
05:34 gywang malinoff, problem resolved, thank U
05:34 malinoff gywang, cool! What was that?
05:34 anuvrat joined #salt
05:34 gywang os_family doesn't match
05:35 gywang we customed it
05:36 danelip Is there a situation that a masterless salt command will act differently than a remote one, when run as the same user (root). eg. salt-call --local docker.pull my_private_repo: success. salt '*' docker.pull my_private_repo: Authentication is required.
05:50 m1crofarmer joined #salt
05:52 greyhatpython joined #salt
05:56 Katafalkas joined #salt
06:02 Katafalkas joined #salt
06:03 harkx joined #salt
06:06 moos3 joined #salt
06:07 malinoff danelip, what salt version are you running?
06:07 Outlander joined #salt
06:07 danelip develop
06:08 Katafalkas joined #salt
06:09 danelip it seems that when i run local it uses my .dockercfg but when I run remote it needs pillar credentials
06:12 CeBe joined #salt
06:15 jtang1 joined #salt
06:16 TheThing can I just say, I'm in absolute love with saltstack
06:16 Ryan_Lane joined #salt
06:16 malinoff TheThing, don't look into the source code :)
06:17 TheThing haha
06:17 mosen hehe
06:18 TheThing oh crap, I probably should have waited with saying that until AFTER I ran highstate
06:18 TheThing (just got an error)
06:18 malinoff :D
06:18 mosen I just found it too
06:20 TheThing uhh, that's a weird error
06:21 TheThing ----------
06:21 TheThing ID: nginx
06:21 TheThing Function: service.running
06:21 TheThing Result: False
06:21 TheThing Comment: The following requisites were not found:
06:21 TheThing watch:
06:21 TheThing file: /etc/nginx/conf.d/*
06:21 TheThing how can a requisite not be found if the path and folder exists?
06:21 TheThing I'm confused
06:21 malinoff TheThing, http://pastie.org is a more comfortable place to paste things
06:21 TheThing Indeed
06:21 TheThing wait...
06:21 TheThing I think I know what it's complaining about
06:21 malinoff TheThing, requisite specifiers should also be managed by salt
06:21 TheThing yeah
06:22 TheThing because I don't have anything (yet) that adds site configs to the conf.d
06:22 TheThing it can't find anything to watch
06:22 mosen can you glob there? i didnt know
06:23 TheThing which is unusual cause I always thought "watch" meant it also watched it for changes also in the minion filesystem and not only in salt states
06:23 TheThing if you catch my drift
06:23 malinoff TheThing, well, you have to write a state which will put something in /etc/nginx/conf.d. This state will have an ID, which you will use in watch: requisite
06:23 mosen i think it only relates to other things declared in salt
06:24 malinoff TheThing, no, salt does not know anything about local filesystem, requisites should be managed by salt
06:24 malinoff if you think about it, it makes sense, when you're using a configuration management tool, you must not make any changes by your hands directly on a remote machine
06:25 TheThing Yeah
06:25 malinoff instead of that, you should modify a configuration file that is managed by that CM tool
06:25 TheThing the reason why I thought it was possible is because of this: https://github.com/saltstack/salt/issues/1734#issuecomment-7431646
06:27 TheThing I'm assuming it does not work the way it was intended
06:27 malinoff TheThing, afaik it is not possible right now
06:28 TheThing well, no biggie, good to know these things before hand :)
06:29 malinoff TheThing, http://madduck.net/blog/2013.02.01:a-botnet-for-configuration-management/ - a bit more things before hand
06:38 TheThing lol
06:39 mosen Halite looks good, I was wondering about minion history though
06:39 mosen I wrote a tiny daemon to pump salt master zmq events into elasticsearch, so that looks workable
06:48 timc3 joined #salt
06:49 jalaziz joined #salt
07:00 ml_1 joined #salt
07:04 chiui joined #salt
07:15 Ryan_Lane joined #salt
07:17 Flusher joined #salt
07:22 CeBe joined #salt
07:24 alanpearce joined #salt
07:33 linjan_ joined #salt
07:35 slav0nic joined #salt
07:40 linux_ joined #salt
07:42 vu joined #salt
07:46 n8n joined #salt
07:50 timc3 joined #salt
07:53 aquinas_ joined #salt
07:54 Lomithrani joined #salt
08:02 mateoconfeugo joined #salt
08:07 darkelda joined #salt
08:16 TheThing joined #salt
08:22 thart joined #salt
08:23 thart anyone know how to get salt-ssh working with just a salt master. commands return nothing.
08:23 bhosmer joined #salt
08:23 thart if salt-master service is running I get "unable to bind socket" error
08:32 poswald joined #salt
08:40 mrTango joined #salt
08:47 millz0r joined #salt
08:49 jdmf joined #salt
08:51 giantlock joined #salt
08:56 londo_ joined #salt
08:56 thart anyone know how to get salt-ssh working with just a salt master. commands return nothing.  if salt-master service is running I get "unable to bind socket" error
08:59 malinoff thart, https://github.com/saltstack/salt/issues/10140
09:03 thart yea I have master public interface set to non 0.0.0.0 - and that page shows that the error shows but also works. for me - it does not work.
09:03 alanpearce joined #salt
09:12 thehaven_ joined #salt
09:16 vu_ joined #salt
09:27 TyrfingMjolnir joined #salt
09:30 aiden_luo joined #salt
09:37 ggoZ joined #salt
09:38 TyrfingMjolnir joined #salt
09:39 linjan__ joined #salt
09:44 Lomithrani " GPG error: http://debian.saltstack.com wheezy-saltstack Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B09E40B0F2AE6AB9"    Has it happened to anyone ?
09:46 agronholm Lomithrani: did you add the key?
09:46 malinoff Lomithrani, http://docs.saltstack.com/en/latest/topics/installation/debian.html#import-the-repository-key
09:46 Lomithrani oh right :/
09:47 TyrfingMjolnir joined #salt
09:56 viq joined #salt
10:02 ixokai joined #salt
10:11 roby77 joined #salt
10:12 roby77 !lista
10:12 roby77 left #salt
10:20 ze- salt-run error.error (which does nothing...) takes 45-60s to run. Any idea how to seek what takes that much time?
10:35 asd joined #salt
10:36 elfixit joined #salt
10:39 bhosmer joined #salt
10:46 bernieke joined #salt
10:47 veselin joined #salt
10:48 veselin Hello all, I've recently started seeing the following: '[salt.modules.cmdmod][INFO    ] Executing command 'iptables --help' in directory '/root''  , when running highstate on the minions. I do not call iptables anywhere in the state files. Any idea how to trace what is invoking this cmdmod?
10:52 viq veselin: is this masterless setup, or you have master and the minions processes do keep running?
10:52 viq Because to me it sounds like salt trying to recognize what it has available, thus support for what it should enable
10:52 veselin viq: I have a master and minions fetching states from it.
10:53 veselin viq: the 'iptables —help' gets called multiple times during the highstate run for some reason.
10:55 babilen viq: Did you sort out your GitFS fuckup?
10:56 viq veselin: hm, don't really know then...
10:56 viq babilen: no, I also called it a night not long after, and didn't get a chance to look today yet
10:57 babilen ack
11:00 viq There's an update to 2014.1.5 available, so I'll first do that
11:00 rigor789 joined #salt
11:04 rigor789_ left #salt
11:07 kuL4 joined #salt
11:08 kuL4 hi guys, is there a way to restrict cmd.run to just set of commands for set of users?
11:08 malinoff kuL4, use system tools - like sudo
11:11 vbabiy joined #salt
11:13 kuL4 malinoff: salt by default is running as root correct? so to exec cmd.run sudo is needed?
11:14 malinoff kuL4, yes, salt is running as root by default and sudo is not needed
11:14 malinoff but you can use it to restrict access
11:15 malinoff there is now white/blacklisting in salt afaik
11:15 malinoff no*
11:16 agronholm salt update? not in launchpad at least
11:16 agronholm still 2014.1.4
11:16 kuL4 malinoff: thx that is what I actually meant, problem is when have root on master or 1 of the minions you can screw lots of servers quite easily
11:16 viq well, arch and openbsd have 2014.1.5 ;)
11:16 dsolsona joined #salt
11:16 agronholm I'm waiting for 2014.1.5 to be able to run salt as non-root
11:17 TheThing I'm waiting for etcd integration :3
11:17 agronholm it doesn't work on 2014.1.4 due to a bug that was fixed in 2014.1.5
11:17 TheThing oh and pillar extend
11:17 agronholm what's that?
11:17 kuL4 Debian 2014.1.5 in sid
11:17 malinoff lol finally they implemented pillar extend
11:17 TheThing I don't think they did xD
11:17 malinoff Uhm
11:17 malinoff You just said that
11:17 TheThing I blogged about a work-around though
11:17 agronholm he said he's waiting for it
11:18 malinoff Ah
11:18 agronholm not that it's done
11:18 TheThing well... they had a pull request that implemented !extend
11:18 Manu joined #salt
11:18 agronholm but was it actually pulled?
11:18 TheThing but that one has already been commited to master
11:18 TheThing but I think that was not for pillar but I'm confused
11:19 Guest43233 left #salt
11:19 viq TheThing: master != 2014.1.x
11:19 TheThing https://github.com/saltstack/salt/pull/10625 <-- see here
11:20 TheThing but I already tried pulling master-branch from github and run that but the !aggregate was still not working for me
11:21 viq It shows as being merged into develop, which will be helium or even further now, but not hydrogen (2014.1)
11:21 TheThing yeah but I tried pulling develop branch
11:21 TheThing but it was still complaining about missing !aggregate keyword in my pillar data
11:21 TheThing so I probably did something wrong
11:21 ggoZ joined #salt
11:21 viq hm
11:22 TheThing but I'm very excited for helium :3
11:22 TheThing both etcd and !aggregate \o/
11:23 TheThing according to that pull request
11:23 TheThing we shall see :3
11:25 viq babilen: so yeah, upgrade didn't help
11:25 Lomithrani joined #salt
11:26 madduck malinoff: I am revisiting the botnet idea, so if you're interested…
11:26 viq babilen: here's my whole master config http://pbot.rmdir.de/t6Bt_pC6M4wvERmmsJdJ_g
11:26 malinoff madduck, I'm all in :)
11:27 malinoff madduck, since I'm working on my own remote execution tool, your thoughts would be appreciated
11:27 madduck malinoff: https://bugzilla.mindrot.org/show_bug.cgi?id=1256 would be a great simplification. I hope to find the time soon to write a spec. Meanwhile, http://www.debian-administration.org/users/dkg/weblog/68 might be the ticket to get sockets on both sides.
11:28 viq madduck: botnet idea?
11:28 madduck viq: http://madduck.net/blog/2013.02.01:a-botnet-for-configuration-management/
11:28 malinoff the first one returns 502
11:28 madduck basically, persistent SSH connections with unix sockets on both sides, and then you can do remote execution or salt or anything on top.
11:29 malinoff madduck, I found amqp broker is much more useful
11:29 madduck malinoff: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=236718
11:29 madduck malinoff: I don't think remote execution or configuration should be based on a message queue, but I'd like to take a look; where?
11:30 malinoff madduck, it is in a private repo right now, but once I will expose it
11:30 malinoff I hope, in the end of June/middle of July
11:31 malinoff amqp provides everything - strong persistent connections, heartbeats, message expiring, caching, access control, failover strategies, etc etc
11:32 malinoff Ah, also, high availability deployments
11:32 madduck well, sounds interesting, especially if you make use of known-good encryption and techniques, rather than reinventing wheels like Salt does
11:32 malinoff madduck, I don't :)
11:32 madduck ah, okay; then I might look in 7 years ;)
11:33 malinoff Well, I like the general salt approach, but my approach is based on newer technologies, like ECC instead of RSA
11:33 viq Doesn't amqp support SSL?
11:34 malinoff viq, it is, but SSL/TLS is a pain, and NOBODY implemented CRLs
11:34 madduck salt's networking and crypto layer are IMHO flawed in many ways, and any new tool implementing crypto is hardly going to be useful for years.
11:34 madduck this is why I want to implement the botnet using known technologies, like OpenSSH
11:36 malinoff madduck, ssh has one thing that prevents me to use it - you can't manage nodes behind firewalls, or you need an agent. But users will complain that you actually don't need an agent, because you have sshd
11:36 malinoff also, it's quite slow
11:36 malinoff even with control sockets
11:36 madduck depends on the algorithm used.
11:36 madduck And yes, the thing about firewalls is easy to address btw
11:37 madduck my botnet can have connections either way, client→server or server→client; at the layer of the unix domain sockets, it doesn't matter anymore who created the connection.
11:39 malinoff madduck, well, with things I use it's not very difficult to drop all crypto-related and switch from amqp to ssh :)
11:39 malinoff if it will be a real security concern
11:41 madduck of course it is a security concern. you are talking remote execution here!
11:41 malinoff Well, using e=1 in RSA is a security concern, not using RSA at all
11:42 madduck reimplementing crypto or using unmaintained libraries is a security concern.
11:42 madduck salt is a security concern, yes.
11:42 malinoff That's why I use a small wrapper around pyOpenSSL and waiting for cryptography to be able to deal with ECC
11:43 ekristen joined #salt
11:43 TheThing I just noticed the downside of using saltstack to manage iptables rules.
11:43 TheThing Accidentally typo'd the role required for it and it reset all the iptables rules on my router locking myself out from all my machines :|
11:44 malinoff TheThing, lol
11:44 ekristen anyone using salt stack with spot instances or auto-scale groups in ec2?
11:44 babilen Could it be that custom grains aren't immediately available? I see strange behaviour in that I have two {% if grains['foo'] %} statements in *one* file and it is true (as it should) be only for the second.
11:45 babilen I get the right value when I run "grains.items foo" though, but my impression is that the grain might not be defined in the dict handed to file.managed files that use jinja as renderer
11:47 saravanans joined #salt
11:49 jeffrubi` joined #salt
11:52 TheThing uhh, does salt-master run highstate default on new clients?
11:52 TheThing seems it doesn't
11:52 diegows joined #salt
11:52 viq TheThing: it doesn't
11:53 viq TheThing: it could if you told it to
11:53 TheThing interesting, I'm listening
11:53 viq Two ways to do it: via reactor, or via minion config
11:54 TheThing ahh, I see
11:54 TheThing thanks
11:54 TheThing forgot about reactior (again)
11:54 viq :P
11:55 TheThing *reactor
12:03 xmj joined #salt
12:09 TheThing Hmm, having a slight error reading pillar data. Getting 'list' object has no attribute '<name>' but when I do pillar.items on said machine, I can see the data clearly: http://pastie.org/private/tnqoziaa6wlwl5nzsqt1ww
12:10 blarghmatey joined #salt
12:10 babilen This is ludicrous ... I have a file that contains, basically, something like http://paste.debian.net/105267/ and I get "bar" on the first one and "foo" on the second.
12:11 babilen (file.managed with jinja as renderer/template)
12:11 babilen That grain works as expected in other files.
12:11 babilen (and yes, I copied that verbatim and only replaced the values)
12:12 blarghmatey joined #salt
12:13 bhosmer joined #salt
12:14 ekristen TheThing: you’ve defined the values of mysql as a list
12:15 TheThing oh my god you're absolutely right
12:15 TheThing I forgot I added the "- " in front
12:15 TheThing my mistake
12:15 ekristen yeah remove that and you should be good to go
12:15 ekristen babilen: whats the problem?
12:16 rnts joined #salt
12:19 joehh babilen: salt_0.17.5+ds-1~bpo70+1 is now in the NEW queue for backports - thanks to jchristau
12:21 babilen yay
12:22 babilen ekristen: Well, I want both values to be the same. There is *no reason* at all for the *same test* to return True everywhere and false at one point.
12:22 babilen At least it does that consistently, but I have no idea why
12:22 jrdx joined #salt
12:24 to_json joined #salt
12:24 ekristen babilen: so the first and second ones — same state file? separate ones? separate hosts? same hosts?
12:24 babilen ekristen: It's the same host, but I would double-check again.
12:25 babilen ekristen: I just don't see it -- I am sure it is some stupid mistake :)
12:25 cliffstah joined #salt
12:25 ekristen well the only thing I could think of is that the grains dynamic file might not have been called yet to populate the field, other then that, as long as your copy and paste didn’t get rid of a typo, everyhting is the same
12:27 jrdx joined #salt
12:28 babilen ekristen: Hmm, for some reason there was an old file in the master cache. I removed /var/cache/salt/gitfs and it works now (typically run fileserver.update)
12:28 babilen I might find some time to look into that later, works as expected now *shrug*
12:30 alanpearce joined #salt
12:31 ifur joined #salt
12:33 miqui joined #salt
12:37 kuL4 left #salt
12:37 ipmb joined #salt
12:42 bhosmer joined #salt
12:45 darkelda joined #salt
12:49 mgw joined #salt
12:54 yidhra joined #salt
12:55 Tekni joined #salt
12:57 saravanans joined #salt
12:58 saravana_ joined #salt
13:00 alanpearce joined #salt
13:02 ccase joined #salt
13:07 veselin left #salt
13:11 racooper joined #salt
13:14 ajprog_laptop joined #salt
13:15 faeroe joined #salt
13:31 viq Can minions access all the files in /srv/salt or only those master tells them/knows about?
13:32 bitnibble joined #salt
13:32 bitnibble So, I'm trying to run:  salt-cloud -M etc/salt/master -C etc/salt/cloud -V etc/salt/cloud.profiles -m etc/salt/cloud.map
13:32 viq Or in more words: if I run salt-master as a dedicated user, and set /srv/salt as home of that user, therefore ssh keys are in /srv/salt/.ssh - can minions access those keys?
13:32 rawzone joined #salt
13:33 bitnibble in other words, using the etc/salt in our devops project rather than a system-wide install
13:34 bitnibble There's a 'user' setting in etc/salt/cloud that needs to be set to avoid the error: [CRITICAL] Salt configured to run as user "root" but unable to switch.
13:34 bitnibble How do I specify 'current system user' please so this works for everyone?
13:34 Katafalkas joined #salt
13:35 jchen etc/salt/master needs to define user: <current user>
13:35 jchen replace <current user> with current user
13:35 jchen not sure if there's a flag that allows you to define the user in the cli command, probably not?
13:36 toastedpenguin joined #salt
13:51 mgw joined #salt
13:53 jeddi joined #salt
13:55 jalbretsen joined #salt
13:57 bitnibble @jchen why does salt care about the current system user anyway. Is there no way to default to the current user running salt-cloud? Seems a bit limiting for a shared devops project. How do people work around it?
14:01 quickdry21 joined #salt
14:01 vu__ joined #salt
14:06 quickdry21 joined #salt
14:07 vejdmn joined #salt
14:07 bitnibble Obviously, everyone having to change 'user' in etc/salt/cloud then change it back before checking in is unacceptable. Can anyone explain why salt-cloud does not pick up the user it is invoked as?
14:08 lazybear joined #salt
14:13 bitnibble I'd take another way to run the above without this error: salt-cloud: error: salt-cloud needs to run as the same user as salt-master, 'root', but was unable to switch credentials. Please run salt-cloud as root or as 'root'
14:13 scoates_ joined #salt
14:14 dude051 joined #salt
14:17 layer3switch joined #salt
14:19 bitnibble So am I SOL on this one then?
14:19 XenophonF hey are there any FreeBSD users here?
14:19 XenophonF i've just written freebsd_groupadd.py and could use some testers
14:28 Katafalkas joined #salt
14:29 babilen Is there a way to get rid of a job (cmd.run) that is simply not returning?
14:29 Katafalkas joined #salt
14:32 penguin_dan joined #salt
14:36 dimeshake joined #salt
14:37 cheus argh. note to self, prior to `enhancing` a module function, first check if it works to begin with. :-p
14:37 TheThing hahaha
14:37 TheThing well, could be worse
14:37 cheus That's a good half hour of debug I'll never get back
14:38 TheThing I'm using github to repo my /srv/salt and I accidentally pushed my private ssl key to the public github repo
14:38 cheus TheThing, Yes. That would be worse.
14:39 babilen TheThing: That should *never* be possible. In fact I would *only* save it in a private pillar that is not hosted on Github at all.
14:39 TheThing Worst part is it's the private ssl key used for the ssl certificate that is now currently being validated... which means once it is validated, I'll have to generate a new certificate D:
14:40 Katafalkas joined #salt
14:42 cheus babilen, Aye. We do something similar; wrote a little formula for an annoying tight pillar server that only responds to localhost pk's on the salt master. Production pillar changes require ssh'ing to the salt master, modifying a user-local clone, then pushing that to a central localhost repo.
14:43 bitnibble Am I the only one in the world trying to run salt-cloud in masterless mode by different users from within a shared project?
14:43 Teknix joined #salt
14:44 babilen cheus: yeah, exactly
14:45 babilen cheus: I intentionally made it a little awkward to use so that sensitive information is very unlikely to leak by mistake (oh, did I just put all our keys to *that* remote?)
14:45 babilen *push
14:45 vu joined #salt
14:45 jchen bitnibble: if the users are running salt-cloud on their local computers, then they can run it as root, no?
14:46 bitnibble @jchen I would not ask users to run anything on their dev machines as root that does not affect their system in a way that required root. Would you? At a guess I'd say the answer was for salt/utils/verify.py:check_user() to only actually check the username if file_client is not "local"? Does this sound like something you would accept a patch for or should I be taking a different approach?
14:46 AdamSewell joined #salt
14:46 MZAWeb joined #salt
14:47 bitnibble It's bad enough that wget saltstack.org|sudo sh is the way salt is expected to be installed.
14:47 Gareth morning
14:47 jchen ? saltstack has packages everywhere
14:48 bitnibble @jchen: since this command does not actually require local root privileges for anything, why would I give it root?
14:49 bitnibble @jchen: not current ones. And that wget|sudo sh is the recommended way according the docs the last time I read the intro.
14:49 cheus babilen, Yep. With ours, someone would have to very explicitly and intentionally take steps to move that data off the master. At the end of the day, it's not bulletproof, but we at least get individual user commits for blame purposes and knowledge that no pillar leak could be classed as a mistake or ignorance.
14:49 bitnibble Anyway, that's another issue.
14:50 babilen cheus: Yeah, I was simply trying to make it explicit that "this data should stay on the master" and to guard against mistakes :)
14:51 viq Can minions access all the files in /srv/salt or only those master tells them/knows about?
14:51 viq Or in more words: if I run salt-master as a dedicated user, and set /srv/salt as home of that user, therefore ssh keys are in /srv/salt/.ssh - can minions access those keys?
14:51 cheus babilen, I know it's a broken record but I hope some day, someone comes up with a secure solution for the 'pillar problem'
14:53 babilen cheus: Well, you *have* to be able to access it somehow. Ansible does this by forcing the decryption of local data, salt gives you pillars that you can guard.
14:54 TyrfingMjolnir joined #salt
14:54 ekristen joehh: any indea when the next release is happening, really anxious to get this docker issue resolved :)
14:55 cheus babilen, Yeah. They're both good enough, for certain but I can't help feeling that somewhere, out there, is a better way it's just not been welded together.
14:55 bitnibble @jchen: do you think the the patch that I described would be accepted? There's no way I can/would ask other devs to run this code as root on their system without justification.
14:56 babilen cheus: I seriously can't think of a different approach. You either make the data available to a process in its unencrypted form and make sure that nobody else can access it *or* you have to decrypt the data manually whenever it is needed.
14:56 jcsp joined #salt
14:57 babilen cheus: There might be a nicer way to automate that (e.g. a keyring for salt that is being made available to salt manually ("you cannot run this state as salt cannot access encrypted values in foo.bar and quux.baz. Please unlock the keyring-daemon on the master by running ....")
14:57 babilen )
14:58 jaimed joined #salt
14:58 babilen cheus: That way you could have your sensitive data in encrypted form in your repositories and the master could still access it ..
14:58 jchen bitnibble: idk, i dont make that decision. you should probably post on the ML/issue tracker
14:59 babilen cheus: One could even unlock that keyring by default on the master (security risk?) if one doesn't want to deal with this.
14:59 bitnibble @jchen: so my request does not seem unreasonable to you?
14:59 babilen Hmm, I would actually like that.
15:00 jchen honestly for me this problem is solved by either 1) tell devs to prepend command with sudo or 2) giving devs access to a salt master wherein they have sudo access to salt* commands
15:00 jchen where*
15:00 thayne joined #salt
15:00 cheus babilen, Aye, and  available to a process is different to being available to a user (eg, I may not trust all of my admins). I'd also like to put the data, at rest, in other non-master locations. Right now, that would be more insecure since at-rest data anywhere else (eg, a db cluster) is potentially exposed and it's just another open port to the master we'd want to avoid.
15:00 babilen something like: ENCRYPTED:foo.bar.baz: DATA in your pillars that will use the foo.bar.baz key in your keyring on the master. Then "salt add-encryption-key foo.bar.baz s3cRiT" and a way for salt to unlock that automatically.
15:01 babilen (or "salt-enc add-key ...")
15:02 bitnibble @jchen: do you think all salt commands should run as root then?
15:02 bitnibble @babilen: I'm working towards a solution involving pass (or actually another_pass)
15:04 lionel joined #salt
15:04 eriko joined #salt
15:06 jsmith joined #salt
15:06 MZAWeb joined #salt
15:08 TyrfingMjolnir joined #salt
15:15 conan_the_destro joined #salt
15:15 mgw joined #salt
15:16 pviktori joined #salt
15:20 PI-Lloyd joined #salt
15:21 PI-Lloyd Hi, is there a way to have salt-cloud provision and attach disks to GCE instances via profile/provider configs, or is it purely from command line only?
15:24 anuvrat joined #salt
15:27 venuR joined #salt
15:29 smcquay joined #salt
15:30 ajw0100 joined #salt
15:30 mgw1 joined #salt
15:31 venuR left #salt
15:34 mgw joined #salt
15:37 faeroe joined #salt
15:39 aubsticle joined #salt
15:46 [diecast] joined #salt
15:47 mateoconfeugo joined #salt
15:48 layer3switch joined #salt
15:49 bitnibble left #salt
15:53 TyrfingMjolnir joined #salt
15:54 darkelda joined #salt
15:57 BrendanGilmore joined #salt
15:57 to_json joined #salt
15:59 arthabaska joined #salt
16:01 m1crofarmer joined #salt
16:02 pdayton joined #salt
16:03 dude051 joined #salt
16:03 mgw I have a test setup with master and minion running on the same host. minion is getting stuck at "Attempting to authenticate with the Salt Master at 127.0.0.1" and then "SaltReqTimeoutError: Waited 60 seconds"
16:03 mgw I've verified that salt master is listening (via netstat -l)
16:03 Lomithrani have you tried with the uri ?
16:04 mgw both are in debug
16:04 Lomithrani rather than 127.0.0.1 ?
16:04 mgw The config actually has 'localhost'
16:04 mgw it is resolving to 127.0.0.1
16:04 mgw It was working previously… I'm not sure what happened
16:04 mgw I have one idea
16:05 mgw which is that my clock was skewed by several days, but has now been resolved
16:05 troyready joined #salt
16:05 mgw the system is a virtual box vm
16:06 scoates mgw: tried restarting minion + master since fixing the skew?
16:06 mgw yes
16:06 mgw several times
16:06 mgw scoates: ^
16:07 mgw I also verified that I can telnet to 127.0.0.1:4505 and 4506
16:07 aquinas_ joined #salt
16:07 Lomithrani I have had the same problem but not on localhost config but you could still try to delete the key
16:07 Lomithrani and retry
16:08 Lomithrani I've had conflict in key with the names
16:08 rallytime joined #salt
16:08 rlarkin joined #salt
16:08 teskew joined #salt
16:09 Lomithrani though I highly doubt that could happen in localhost
16:09 napper joined #salt
16:09 tligda joined #salt
16:09 mgw lomithrani: I already did that
16:09 mgw and the key never shows up again for acceptance
16:10 mgw literally nothing logs in master at debug either
16:10 mgw when the minion attempts to auth
16:12 jergerber joined #salt
16:13 Lomithrani :/ Sorry then I'm quite new to salt I wish I could have helped you but I'm out of idea
16:14 Theo-SLC joined #salt
16:15 anuvrat joined #salt
16:17 to_json joined #salt
16:21 KyleG joined #salt
16:21 KyleG joined #salt
16:22 mspah_ joined #salt
16:23 possibilities joined #salt
16:25 mgw Is it normal for debug logs to show "Missing configuration file: /root/.salt"?
16:26 mgw I'm on Ubuntu using the packaged init script
16:26 mgw later in the startup process it logs "Reading configuration from /etc/salt/master"
16:27 timoguin i would think that'd be more of an INFO log, since it tries to find a per-user config first
16:28 TheThing joined #salt
16:30 mgw so… it seems to be caused by an ext tops module I was working on :-/
16:31 mgw It seems rather odd that that would effect authentication
16:32 ipalreadytaken joined #salt
16:32 dlam joined #salt
16:32 rallytim_ joined #salt
16:32 mgarfias How does gitfs work with pillar with regard to environments?
16:33 rallytim_ joined #salt
16:35 babilen mgarfias: branches are environments (which is a complete mess if you want to merge between branches)
16:36 thayne joined #salt
16:36 rallytime joined #salt
16:38 alanpearce joined #salt
16:40 kossy joined #salt
16:40 babilen mgarfias: You probably want (at least) two repositories in which you have pillar sls files in the one and top.sls in the other. (which is being merged across all branches)
16:40 cheus Getting some weird quoting behavior with one of the modules that basically calls cmdmod._run() underneath it. Are there known issues with  quotes and escaping that require workarounds?
16:41 jimklo joined #salt
16:41 mgarfias so a repo for states, a repo for pillar, and top.sls somewhere else?
16:42 TheThing joined #salt
16:42 babilen mgarfias: No, as many repos for your states as make sense + one for top.sls, same for pillars
16:42 utahcon does salt.states.service.running just check if a service is up, or does it restart it?
16:42 babilen Otherwise you can forget merging between branches
16:42 joehillen joined #salt
16:43 cheus utahcon, Doesn't restart
16:43 cheus utahcon, But will start it if not
16:43 utahcon hmm... ok
16:43 cheus utahcon, It has a check inside to determine if it has to do anything like start a service.
16:45 utahcon cheus: thanks, looks like I meant to type salt.modules.service instead
16:45 utahcon thanks!
16:46 shaggy_surfer joined #salt
16:47 pssblts joined #salt
16:50 redondos joined #salt
16:50 redondos joined #salt
16:52 kiorky_ joined #salt
16:55 moos3 whats the proper way to do subs in a stack, like i have apache/init.sls but how do I do a version specific sub sls file
16:58 bhosmer joined #salt
16:59 timoguin moos3: like install a different version of apache?
17:00 chiui joined #salt
17:01 wendall911 joined #salt
17:02 smcquay I am confused by the apache-libcloud import error on minion launch when pip freeze claims it's installed. anyone else seen this?
17:02 mgw Where are customer tops modules supposed to go?
17:02 mgw s/customer/custom/
17:03 kballou joined #salt
17:03 pdayton joined #salt
17:03 dude051 joined #salt
17:04 schimmy joined #salt
17:05 forrest joined #salt
17:05 joehh joined #salt
17:05 schimmy1 joined #salt
17:05 kermit joined #salt
17:15 mgw basepi: do you know where custom master_tops belong? I can't find it documented anywhere.
17:15 matrix3000 joined #salt
17:19 ipalreadytaken joined #salt
17:19 basepi It's possible that you could define an extension_modules entry for it, but I'm not sure if it will work or not:  http://docs.saltstack.com/en/latest/ref/configuration/master.html#extension-modules
17:20 basepi I don't know if extension_modules "just works" or if we have to add each subsystem to it
17:20 UtahDave joined #salt
17:20 jtang1 joined #salt
17:21 thehaven_ joined #salt
17:25 JeroenH_ joined #salt
17:25 shaggy_surfer joined #salt
17:26 faeroe joined #salt
17:27 ajolo joined #salt
17:28 jtang1 joined #salt
17:28 Ryan_Lane joined #salt
17:31 jtang1 joined #salt
17:32 featherking joined #salt
17:34 davet joined #salt
17:35 featherking is there a great way to check if an iptables rules exists? looking in the state module there is a chain_absent but it doesnt go down to the rule. I am trying to setup a rule for a samba server if it doesnt exist, but append seems to add it every time the state gets run
17:35 featherking *adds it when using append in the state
17:36 dstokes featherking: `iptables -C <chain> <rule>`
17:36 JasonSwindle joined #salt
17:37 dstokes adding a rule multiple times is valid in iptables, and there isn't currently a method for idempotent rule addition. use cmd module instead
17:38 dstokes i.e. `name: iptables -C ... || iptables -A <chain> <rule>`
17:39 featherking so no module functionality
17:39 arnoldB featherking: I can recommend to use ferm as a iptables frontend. (salt part: https://github.com/bechtoldt/ferm-formula)
17:39 alanpearce joined #salt
17:39 arnoldB if you have a lot of complex rules you might love it
17:40 dstokes featherking: afaik, there is no idempotent way to add rules via salts iptables state (short of wiping and recreating rules on fly)
17:46 mgw basepi: thanks, I was starting to think that I might have to symlink into the actual salt source :-(
17:46 featherking dstokes: thanks i just wanted to make sure i wasnt overlooking something. I couldnt see anything in the documentation
17:46 mgw Testing, and if so, I'll fix the loader.
17:47 featherking dstokes: my iptables doesnt have -C but I might do something like  iptables-save | grep -- 445
17:50 anuvrat joined #salt
17:50 dstokes featherking: that works too ;)
17:51 dstokes it's not ideal, but it's really iptables' fault if you ask me. shouldn't allow creating duplicate rules..
17:51 mgarfias hey is there any plans to make salt-cloud also manage aws non-instance things like sec groups, elb, etc?
17:52 dstokes featherking: if you know the rules ahead of time, you could also just use a template in conjunction with  `iptables-restore`
17:53 arnoldB dstokes: => http://ferm.foo-projects.org/download/2.2/ferm.html :)
17:53 arnoldB ferm does several rule checks
17:54 druonysus joined #salt
17:54 dstokes yeah, that works too, but i'm old fashioned
17:54 dstokes was using ufw for a while
17:54 davet joined #salt
17:54 TheThing joined #salt
17:55 arnoldB me too but I prefer simple configuration files over cimplicated salt state hacks
17:55 arnoldB s/cimplicated/complicated/
17:56 timoguin mgarfias: there are several new AWS modules in develop that use boto
17:56 timoguin security groups and elb are there
17:56 timoguin there are a few others
17:57 mgarfias so a matter of time then?
17:57 timoguin yea, the RC is slated to be cut in the next few weeks.
17:58 mgarfias sweet
17:58 timoguin https://github.com/saltstack/salt/tree/develop/salt/modules
17:58 timoguin see all the ones prefixed with boto_
17:59 arthabaska joined #salt
18:02 timc3 joined #salt
18:03 sroegner joined #salt
18:10 Theo-SLC I have another problem with tomcat7 at salt.  /sbin/service reload will not work with the tomcat7 init script.  It must use service restart.  can I specify a restart instead of a reload on my service.running 'watch' function?
18:11 chrisjones joined #salt
18:11 thedodd joined #salt
18:11 to_json joined #salt
18:12 AdamSewell joined #salt
18:13 mgw joined #salt
18:14 Theo-SLC I'm going to try this: fully_restart: True
18:14 to_json joined #salt
18:15 schimmy joined #salt
18:15 dlam hmm is there a way to run a separate state file *after* its done everything in the current one?
18:16 forrest dlam, include the first state file in the second one
18:16 forrest the included file will run first
18:17 dlam ya maybe i want something like include:  but do-it-after  (it runs last)
18:17 forrest ?
18:17 forrest if you want it to run last, include the file you want to run first, in the file you want to run last
18:17 forrest does that make sense?
18:18 dlam ohhh i get what you mean
18:18 forrest cool
18:19 schimmy joined #salt
18:20 MZAWeb joined #salt
18:21 ml_1 joined #salt
18:22 Theo-SLC fully_restart: True .. works.  I'm going to do a pull request on docs to make this more clear
18:23 conan_the_destro joined #salt
18:23 pdayton joined #salt
18:24 Ryan_Lane why would jinja int fail and return 0?
18:24 Ryan_Lane {{ (grains['mem_total'] * 1024) * 0.10 | round(1, 'floor') | int }}
18:24 Ryan_Lane ^^
18:25 Ryan_Lane that's giving me back 0
18:25 Ryan_Lane a float is definitely getting passed in
18:25 Whissi joined #salt
18:26 JordanTesting Anyone seen this before? http://pastebin.com/YukXuA1s
18:26 shaggy_surfer joined #salt
18:27 JordanTesting restarting the salt-master fixed it, but... odd
18:27 ramteid joined #salt
18:28 manfred JordanTesting: it looks like you might have had an old version of msgpack?
18:28 Joseph joined #salt
18:28 JordanTesting although now after the restart I am getting...
18:29 JordanTesting huh, no it started doing it again
18:29 manfred what version of salt?
18:29 JordanTesting these machines were working with eachother previously... mm hang on
18:29 featherking can a watch statement watch multiple files or a directory?
18:29 perfectsine joined #salt
18:30 arnoldB featherking: watch accepts an array of multiple hashes
18:30 manfred featherking: a watch statement watchs other states, and it can watch however many statesa
18:30 carmony featherking: a watch statement watches based off of a salt state
18:31 arnoldB featherking: https://github.com/bechtoldt/httpd-formula/blob/master/httpd/init.sls#L37 :)
18:31 JordanTesting manfred: salt-master 2014.1.3, salt-minion 2014.1.4 (Hydrogen)
18:31 featherking so if my watched state is a file.recurse on a directory then the watch will fire if any of those are changed
18:31 manfred JordanTesting: http://docs.saltstack.com/en/latest/faq.html#can-i-run-different-versions-of-salt-on-my-master-and-minion
18:31 tristianc|Phone joined #salt
18:32 JordanTesting yeah, they should actually be the same, master must not be updating... bbuttt they were working fine previously
18:32 JordanTesting I will fix that and re-test though
18:32 JordanTesting for the sake of proper form
18:33 perfectsine joined #salt
18:35 windoverwater joined #salt
18:37 logix812 joined #salt
18:45 bhosmer_ joined #salt
18:46 gmoro joined #salt
18:47 smcquay joined #salt
18:47 aw110f joined #salt
18:47 moos3 whats the best way to do a if statement in a sls
18:47 shaggy_surfer joined #salt
18:47 moos3 i have this {% if grains.get('roles') == 'php55' %} but it doesn't seem to be working
18:48 manfred can you share the whole state?
18:48 perfectsine joined #salt
18:48 blarghmatey1 joined #salt
18:48 Joseph moos3: also what do you mean about "not working"? Are you getting an error message or failing to matching a minion?
18:49 JordanTesting manfred: ok, got them up to the same version now - same issue
18:50 windoverwater joined #salt
18:51 mgw Is there a module or runner that shows the tops data? I thought there was, but can't seem to find it. state.show_highstate is the closest.
18:51 possibilities joined #salt
18:52 manfred mgw: you mean the states that will be applied to a server when you run state.highstate?
18:52 mgw manfred: yes
18:52 JordanTesting hmm I was able to remove/readd the minions keys so part of the transport is working
18:52 manfred that is what salt \* state.show_highstate does
18:52 pdayton1 joined #salt
18:53 mgw so, basically, something like {"base": ["foo", "fizz", "fazz"]}
18:53 izibi joined #salt
18:53 mgw the tops structure
18:53 JordanTesting manfred: looks isolated to this particular minion/vm - I will dig in there
18:54 perfectsine joined #salt
18:55 manfred mgw: salt \* state.show_top ?
18:55 mgw yeah, that's it, i was looking for show_tops
18:55 mgw thanks
18:56 windoverwater Hi all.  New to IRC chat, new to salt, searched logs, many pardons in advance.  Trying to use ssh_known_hosts.present, but it adds a duplicate line each time state.highstate is run.  Is there some undoc'ed switch to only add host if not present?  Pilot error?
18:57 UtahDave joined #salt
18:57 Joseph windoverwater: can you show state file?
18:57 Joseph in gisthub
18:58 twobitsprite joined #salt
18:58 doddstack joined #salt
18:58 perfectsine joined #salt
18:58 windoverwater https://gist.github.com/anonymous/a17cee9e5535aaa05cb4
18:59 windoverwater [new to this - did that work?]
18:59 twobitsprite I'm having a problem with user modules... I have a python module in my _modules directory, and it got sync'd to the minion and is at /var/cache/salt/minion/files/base/_modules
18:59 dsolsona joined #salt
18:59 twobitsprite but when I try to call it (either remotely or with salt-call) it says it's not there
18:59 shaggy_surfer1 joined #salt
18:59 JordanTesting uninstalled / reinstalled salt and same issue on this minion :( time to do real work I guess
19:00 Joseph windoverwater: yes
19:00 twobitsprite from the remote, it says "'logins.get_users' is not available.", with salt-call it just says "Function logins.get_users is not available"
19:00 chiui joined #salt
19:00 manfred twobitsprite: can you do salt-call with -l debug and see if there are any errors?
19:01 jY are there any good blog posts on setting up tests for state files?
19:01 moos3 how can you do a if statement on a grain that returns multiple values
19:01 moos3 Joseph no error
19:02 TheThing moos3: You mean like {% if 'test' in grain['roles'] %} or something?
19:02 manfred moos3: salt['grains.get']('some:other:thing') == 'something' if it is a dictionary, if it is returning a list... grains.get('something')[1]
19:02 Joseph moos3: iterate through the array and then do an if condition on each item in the array
19:02 moos3 just grains.get('roles') == 'php55' doesn't seem to match on roles: - php55 - apache
19:02 manfred moos3: if 'php55' in grains['roles']
19:02 TheThing so many answers xD
19:02 TheThing moos3: What manfred said, it's how I've been doing it
19:02 Joseph moos3: manfred's suggestion is better
19:02 twobitsprite manfred: no errors... want me to pastebin it?
19:03 Joseph windoverwater: checking
19:03 manfred twobitsprite: sure, and your module
19:03 TheThing twobitsprite: Use pastie.org instead :)
19:03 manfred salt-call <modules> -l debug 2>&1 | curl -F 'f:1=<-' ix.io
19:04 Ryan_Lane joined #salt
19:04 jimklo joined #salt
19:04 twobitsprite http://pastie.org/9295908
19:05 pdayton joined #salt
19:05 moos3 ok
19:05 manfred how are you syncing it to the minion?
19:05 perfectsine joined #salt
19:05 twobitsprite http://pastie.org/9295913
19:06 twobitsprite with saltutil.sync_all
19:06 manfred twobitsprite: you need a __virtual__()
19:06 twobitsprite I also ran saltutil.refresh_modules or whatever
19:06 twobitsprite manfred: it works on other minions
19:06 openasocket joined #salt
19:07 Ryan_Lane anyone know why using the int filter always gives me back a 0 result?
19:08 aquinas_ joined #salt
19:09 Gareth int filter?
19:09 twobitsprite manfred: what is the __virtual__ for and why does it work on other minions without it?
19:09 Ryan_Lane {{ (grains['mem_total'] * 1024) * 0.10 | round(1, 'floor') | int }}
19:09 Gareth Ryan_Lane: true vs false result?
19:09 Ryan_Lane ah. hm. it has something to do with my parens
19:10 UtahDave __virtual__ isn't actually mandatory.  But if you don't have a __virtual__ function, then the module will be named after the filename
19:10 openasocket weird question: is there an easy way to make a profile which picks a random valid location?
19:10 twobitsprite ok, well, that's what I'm calling it, so it should work, right?
19:10 Gareth UtahDave: hey
19:10 UtahDave hola Gareth!
19:11 Gareth UtahDave: hows it going?
19:11 manfred twobitsprite: what version of salt?
19:12 UtahDave Gareth: good! I spent Father's day eating bacon and hamburgers and other unhealthy buy yummy food!   :)
19:12 Gareth UtahDave: haha nice :)
19:12 Joseph random issue
19:12 Joseph salt master can''
19:12 twobitsprite manfred: salt-minion-2014.1.4-1.el6.noarch
19:13 Joseph t execute commands  on my minions
19:13 Joseph Authentication failure of type "user" occurred.
19:13 Joseph failred to authenticated is thuis user permitted to execute command
19:13 Joseph on 2014.1.4
19:13 Joseph i have removed and added keys back in
19:13 manfred twobitsprite: i don't know how that is succeeding, since the shadow module doesn't return a shadow['pwd'] argument https://github.com/saltstack/salt/blob/2014.1/salt/modules/shadow.py#L46
19:13 Joseph and cleared cached and restarted services
19:14 manfred on any of the extra shadow modules either
19:14 manfred pwd = shadow['pwd']
19:14 manfred pwd = shadow['password'] ?
19:14 twobitsprite manfred: well, I did get a traceback on one minion, but just before that I got an actual result... then on the 10 or so before that I get the "not available" message
19:15 twobitsprite the one it succeeded on might be an older version... but even then, shouldn't I get tracebacks on the others instead of a "not available" message?
19:15 manfred that, i do not know, cause i just tried it, and did a salt \* saltutil.sync_modules, and the module worked fine
19:15 ecdhe joined #salt
19:16 Joseph never mind...i figured it out. I had salt-master hooked up to gitfs and because of that i was getting a general authentication failure
19:16 UtahDave twobitsprite: have you tried restarting the minion service?
19:16 Joseph maybe open an issue against error checking
19:16 twobitsprite yeah, the one that succeeded is version 0.15.1... but still... shouldn't I get a traceback instead?
19:16 twobitsprite UtahDave: yes
19:17 twobitsprite ok, I changed it to shadow['password'] and got the same message
19:19 openasocket I need to spin up multiple instances (many copies of the same image) on Digital Ocean and have them be randomly distributed across the six valid locations.
19:20 jcockhren openasocket: oh cool. :)
19:21 openasocket should I just make six profiles or can I configure the location to be random somehow?
19:21 manfred twobitsprite: can you try a saltutil.sync_modules instead of a sync_all ?
19:22 pdayton joined #salt
19:22 austin987 joined #salt
19:22 twobitsprite manfred: well, the module is synced because it's on the minion...
19:23 jcockhren openasocket: my thoughts are that you have the profiles made. then have a custom module that 'knows' the locations and acts as a proxy to call the salt.clould modules
19:23 mgw joined #salt
19:24 manfred twobitsprite: right, but i want to know the output of sync_modules, because it will tell you what it copies over
19:24 Joseph windoverwater: i am reproducing your problem
19:24 Joseph i think this may be a bug
19:24 jcockhren openasocket: when calling salt cloud, the command line args will take higher precidence than what's in the profile
19:24 funzo joined #salt
19:24 tligda joined #salt
19:24 Joseph UtahDave: ssh_known_hosts.present seems to append the host key over and over again to the file even if the entry is already there. Is this a known bug?
19:24 manfred openasocket: you need one profile per region
19:24 mateoconfeugo joined #salt
19:24 manfred openasocket: there isn't a way to override them on the command line
19:25 UtahDave Joseph: I'm not sure. what version are you on?
19:25 manfred openasocket: you can put them all in a map file, and have it spin up multiple instances from each profile though
19:25 Joseph UtahDave: 2014.1.4
19:25 jcockhren manfred: really? has that changed?
19:25 jcockhren :(
19:25 manfred jcockhren: no, there was never a way to override stuff on the command line
19:25 Joseph UtahDave: someone else  raised this issue so i checked. Its easy to reproduce.
19:25 Joseph UtahDave: version is 2014.1.4
19:25 manfred jcockhren: https://github.com/saltstack/salt/issues/10149
19:25 windoverwater joseph: thanks!
19:26 XenophonF joined #salt
19:26 manfred Joseph: can you test 2014.1.5 ?
19:26 cedwards joined #salt
19:26 Joseph manfred: hmm
19:26 Joseph manfred:
19:26 Joseph sure
19:26 miqui joined #salt
19:26 jcockhren openasocket: I'm wrong
19:26 openasocket manfred: can a map file handle hundreds (possible thousands) of instances in a single map?
19:26 MZAWeb joined #salt
19:26 UtahDave Joseph: Hm. I'm not seeing an open issue with that exact problem.  Would you mind opening an issue?
19:26 manfred openasocket: if you are spinning them all up at once, a map file is the way to go
19:26 manfred openasocket: should be able to
19:26 manfred openasocket: if digital oceans api can handle it
19:26 Joseph UtahDave: sure...though i'll try on 2014.1.5 just to be sure
19:27 openasocket manfred: I'd like to spin them up in batches, so I don't DOS the digital ocean api
19:27 UtahDave Joseph: great idea. Thanks!
19:27 manfred openasocket: there isn't a batch option, but you could do multiple map files
19:27 Joseph UtahDave: is 2014.1.5 in epel repo for centos ?
19:27 chrisjon_ joined #salt
19:27 Voziv joined #salt
19:27 manfred Joseph: should be in testing
19:28 Joseph ahh
19:28 platforms joined #salt
19:28 UtahDave openasocket: You can set  "pool_size: 20"   for example, so salt-cloud will only spin up 20 at a time.  Put that in /etc/salt/cloud
19:28 manfred UtahDave: nice
19:28 manfred i should use that
19:29 kyr0 joined #salt
19:29 cheus Is the 'names ' paradigm baked into all state module processing at the core?
19:29 XenophonF hey UtahDave: I'm getting back around to finishing the MSI installer.
19:29 XenophonF What where those setup.py commands that needed to be run between install and bdist_esky?
19:30 openasocket manfred: is there a more flexible way to handle maps? Like can I make salt-cloud take in a map from stdin ?
19:30 manfred openasocket: i don't believe so
19:30 manfred just a yaml/json file iirc
19:31 manfred cheus: it is baked into the states at the core
19:31 UtahDave cheus: Yes, names is generic
19:31 manfred cheus: every entry in names: gets it's own state
19:31 UtahDave XenophonF: just a sec. Let me post a gist.
19:31 XenophonF np
19:31 XenophonF thanks!
19:31 BrendanGilmore joined #salt
19:32 manfred cheus: which is why I had to do this patch https://github.com/saltstack/salt/commit/b5a48b52fdccb4ebb837df4a7574ab225fb9a634
19:32 openasocket manfred: fine. I'll just need to write a big-ass map
19:32 manfred yar
19:32 pdayton joined #salt
19:33 openasocket manfred: one last question: digitalocean scrubs data when you destroy a droplet by default, but you can pass a query string to override that behavior
19:34 manfred cheus: https://github.com/saltstack/salt/blob/develop/salt/state.py#L478
19:34 cheus manfred, hah. Indeed. Thanks, though I'll admit now I'm even more puzzled than I was.
19:34 UtahDave XenophonF: https://gist.github.com/UtahDave/59eb47e12b113fce6398
19:34 manfred openasocket: that I have no idea, cause I haven't done any work on the digital ocean cloud driver
19:34 openasocket manfred: when I remove instances with salt-cloud, is there a way to insure it does not scrub that data
19:34 XenophonF UtahDave: noted.  Thanks!
19:34 openasocket manfred: that's fine. Thanks for the help, though
19:35 cheus Names just applies all of the settings of its parent state to multiple states, only changing the 'name' argument. Does the paradigm allow other arguments to be passed (eg, can names be a list of dicts)?
19:35 manfred openasocket: https://github.com/saltstack/salt/blob/develop/salt/cloud/clouds/digital_ocean.py#L656
19:35 manfred openasocket: looks like you can just set scrub_data: True or False in your digital ocean provider
19:35 doriftoshoes joined #salt
19:35 timoguin yea it should be definable via the profile
19:35 openasocket manfred: very cool. Thanks!
19:35 manfred cheus: yes
19:35 manfred cheus: oh
19:35 manfred cheus: no
19:36 manfred cheus: names only takes a set of things that have the same arguments
19:36 xzarth joined #salt
19:36 manfred cheus: it just does a deep copy on the chunk, and set the name https://github.com/saltstack/salt/blob/develop/salt/state.py#L482
19:37 cheus manfred, Thank you. Saved me a lot of digging; looks like I will have do some multi-operational processing on my own.
19:37 Joseph UtahDave: still reproducible. I will open a bug
19:37 aquinas_ joined #salt
19:37 manfred cheus: gimme a minute
19:37 cheus manfred, Sure
19:37 UtahDave Joseph: thanks, man
19:39 manfred cheus: hrm, i have to think how to do that...
19:40 cheus manfred, Well it could be done on a jinja level but at the moment I'm tinkering on the git state module. Fixed a couple issues with the git exec module and adding config() management functions to the state module. Wanted to see if I could overload names to set multiple config values but I can use another data structure for that too.
19:41 manfred cheus: sure, but it could also be done inside of state.py if low_name is a dict
19:41 manfred do a .update instead of an =
19:41 cheus manfred, Yep
19:42 Joseph UtahDave: here you go https://github.com/saltstack/salt/issues/13484
19:42 JordanTesting manfred: digging into it, it looks like something in the grains is throwing an error and that causes serialization to bomb out
19:42 UtahDave Joseph++
19:43 twobitsprite manfred: no output, just lists the hostname, a colon, then a blank line, even with -v
19:44 manfred cheus: https://github.com/gtmanfred/salt/commit/28c9f562d02d37c6c19ccbe6a39a22dbb88fb268
19:44 manfred something like that
19:44 manfred twobitsprite: where is the file located on the master?
19:44 manfred and this is after you changed something about the module right?
19:44 JordanTesting manfred: looks like a custom grain one of our dudes wrote was causing an error, and it bubbled up in a very strange way
19:45 manfred JordanTesting: ahh ok
19:45 twobitsprite manfred: /srv/salt/_modules/
19:45 cheus manfred, Now that's an elegant solution.
19:45 manfred twobitsprite: hrm... i am out of ideas, sorry
19:45 manfred cheus: gimme a bit to test it and if it works, i will submit a PR
19:46 cheus manfred, Sure.
19:46 JordanTesting is that worth filing a bug on? the fact that a bad grain is caught in serialization and the error isn't helpful? I only found it by adding a ling that dumps the payload
19:48 linjan joined #salt
19:49 timoguin JordanTesting: adding error messages that make more sense is always pull request worthy
19:55 to_json joined #salt
19:59 cheus style question: making some changes to a module that affects changes adds default values to a couple arguments; according to salt's lint config, that means I should change their order to after non-default args but that obviously would blow backwards compatibility for those relying on order
19:59 cheus lesser evil?
20:00 vejdmn joined #salt
20:01 aquinas_ joined #salt
20:03 forrest cheus, I'd suggest to review other modules to see how it was handled there.
20:07 possibilities joined #salt
20:09 aquinas_ joined #salt
20:09 kyr0 joined #salt
20:09 kyr0 joined #salt
20:12 mrTango joined #salt
20:13 MZAWeb_ joined #salt
20:15 platforms joined #salt
20:15 lude is there a way to run a pkg.refresh before I run any other commands (like if my portage tree is empty, and I want to sync it)
20:16 BrendanGilmore joined #salt
20:20 tristianc|Phone1 joined #salt
20:20 ajolo joined #salt
20:21 Joseph lude: overstate
20:23 lude ty
20:26 seanz joined #salt
20:26 moos3 is there a reason why pkgrepo.managed: cant handle a mirror and baseurl ?
20:26 londo__ joined #salt
20:27 MZAWeb_ joined #salt
20:31 BrendanGilmore joined #salt
20:32 manfred lude: module.run state, and then order: 1 on that state to tell it to be the first to run
20:32 shadfc joined #salt
20:33 windoverwater Joseph:  just checking if you had any luck reproducing problem.  Note - if I manually use file.append, that works as expected
20:34 lude yeah i'm having trouble finding a standalone pkg.refresh state
20:34 ajolo_ joined #salt
20:35 napper joined #salt
20:37 forrest lude, the repo will be refreshed when you try to do an installation
20:37 forrest is that not what you want?
20:37 CeBe joined #salt
20:38 druonysuse joined #salt
20:41 lude well, there's no packages in the db, so there's no match for any packages
20:41 lude so the refresh: True bit doesn't work for me
20:41 lude i need a standalone way to refresh
20:42 forrest lude, what OS?
20:42 lude gentoo
20:42 jimklo joined #salt
20:43 shadfc can someone help me understand this error?  https://gist.github.com/jwineinger/3d91767925791815969a
20:44 timoguin shadfc: that last require should be file: instead of directory:
20:44 forrest damn you timoguin
20:44 * timoguin wins
20:45 forrest beat me by a few seconds
20:45 shadfc why?  does it infer that it should be a directory instead of a file, even if i say file?
20:46 aw110f Hi, I'm on 2014.1.3, and the scheduler setup using pillar isn't triggering.  http://pastebin.com/L5n9RzDB
20:46 timoguin shadfc: no, the require system needs 1) a top-level module that's being called 2) a unique state id
20:46 smcquay joined #salt
20:46 Ryan_Lane I'm just doing something very wrong with jinja? {{ (grains['mem_total'] * 1024) / 10 | round(1, 'floor') | int }} <-- 383795.2
20:46 Ryan_Lane am I using filters incorrectly?
20:47 jdmf joined #salt
20:49 timoguin lude: I could have sworn there was a module/state for portage, but I'm not finding it.
20:50 timoguin worst case scenario you could use cmd.run
20:51 forrest lude,
20:51 jacksontj joined #salt
20:51 lude yeah i mean cmd.run is fine, feels hacky though
20:51 forrest use http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.ebuild.html#salt.modules.ebuild.refresh_db via http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.state.html
20:51 forrest don't use cmd.run
20:51 timoguin oh it's called ebuild
20:51 forrest that noob timoguin doesn't know what he's talking about :P
20:51 timoguin haha
20:52 timoguin i was looking for emerge, portage, gentoo
20:52 forrest yea no
20:52 lude haha burn
20:52 forrest I had to look through most of them as well
20:52 Ryan_Lane -_- I needed to group the entire math function for it to work properly. I hate jinja
20:52 forrest Ryan_Lane, why not just use python?
20:52 Ryan_Lane this is inside of a template file
20:53 forrest ahh
20:53 Ryan_Lane otherwise I want to avoid any difficult renderers
20:53 Ryan_Lane I expect end-user developers to use this
20:53 forrest gotcha
20:54 matrix3000 using python in salt is like using ruby in puppet
20:54 forrest what's with the complexity of that jinja anyways?
20:54 matrix3000 why have a DSL
20:54 Ryan_Lane let me give a little example
20:55 pdayton joined #salt
20:56 forrest seems like it would be easier to just say grains['mem_total'] * 100 and be done with it
20:56 matrix3000 yea
20:56 forrest way simpler, though not quite as accurate, but who cares
20:56 Ryan_Lane forrest: https://gist.github.com/ryan-lane/4ebdb96c9936278833dd
20:57 sygibson__ joined #salt
20:57 forrest heh
20:58 forrest again, why can't you just do {{ (grains['mem_total'] * 100)  }}
20:58 lude for any curious
20:59 lude the magic bit i needed was
20:59 lude module.run:
20:59 lude - name: pkg.refresh_db
20:59 Ryan_Lane forrest: I'm porting something from puppet that someone else wrote
20:59 Ryan_Lane and I'm keeping the logic the same
21:00 forrest Ryan_Lane, and so the pieces fall into place...
21:00 forrest why does the logic have to be identical?
21:00 Ryan_Lane also * 100 isn't functionally equivalent :)
21:00 forrest yea of course it isn't
21:01 Ryan_Lane forrest: because I don't want to modify the behavior on the current systems
21:01 forrest I'm not trying to make it functionally equivalent, I'm trying to make it easier to understand so you don't have to look through the jinja docs :P
21:02 forrest yea I totally understand
21:02 Ryan_Lane heh
21:02 Ryan_Lane * 1024 = bytes...  * 0.1 = 10%
21:02 matrix30001 joined #salt
21:02 Ryan_Lane that's slightly easier to understand than *100
21:02 ckao joined #salt
21:03 williamthekid_ joined #salt
21:03 XenophonF left #salt
21:06 notbmatt Ryan_Lane: why not just {% set foo = salt['grains.get']('mem_total'... %} {{ foo }} ?
21:06 savvy-lizard joined #salt
21:06 notbmatt instead of chaining filters, which is kind of hard to parse anyway
21:07 Ryan_Lane notbmatt: you mean do the math in a couple lines, rather than use filters?
21:07 notbmatt no, I mean use python to do the math, and use jinja to do the printing
21:07 Ryan_Lane when you use set, it uses normal python?
21:07 notbmatt {% %} vs {{ }}
21:07 Ryan_Lane ah
21:08 Ryan_Lane nice
21:08 kyr0 joined #salt
21:08 kyr0 joined #salt
21:08 jimklo joined #salt
21:09 Ryan_Lane hm. I'd need to do imports for that. I'd need math.floor
21:10 bigl0af joined #salt
21:10 cedwards joined #salt
21:11 dstokes i'm trying to use `- sls: state` in a require_in statement but getting an error about the state to be extended not being in the highstate. is this valid syntax?
21:11 forrest dstokes, did you include the state at the top?
21:11 dstokes the state is being included before the require_in
21:11 dstokes forrest: beat me to it ;)
21:11 forrest can you gist your sls?
21:11 lz-dylan joined #salt
21:11 dstokes yeah, one sec
21:12 CeBe1 joined #salt
21:12 dstokes forrest: https://gist.github.com/dstokes/e0ed38d56d2046139ce5
21:12 ksk hey. i want to run salt-master inside an openvz-container - inside such a container lspci does not work - my log is full with " Although 'lspci' was found in path, the current user cannot execute it." -- any idea how to fix or workaround?
21:13 aquinas_ joined #salt
21:13 dstokes forrest: the idea is to make the git repo a requisite of the deploy.rails state
21:15 forrest dstokes, oh I don't think you can use require_in for whole states
21:15 dstokes just `require`? weird..
21:15 moppersmurf joined #salt
21:15 utahcon using salt.states.git.latest and getting an overwrite error, but I have force_checkout: True
21:15 utahcon http://pastie.org/9296542
21:15 utahcon thoughts?
21:16 forrest I'd switch it up and see real quick if it works, I've never seen an example or usage of require_in for an entire sls, mostly because you'd just include the state if you were going to do that :P
21:17 kyr0 joined #salt
21:17 diegows joined #salt
21:18 utahcon http://pastie.org/9296560 this one shows my result
21:20 notbmatt Ryan_Lane: I gotta say, it sounds like you're trying to force a hack to work :)
21:21 Ryan_Lane it's pretty basic math
21:21 forrest Ryan_Lane, dat jinja
21:21 Ryan_Lane if jinja can't do basic math correctly there's a problem
21:21 notbmatt Ryan_Lane: write a custom grain that returns mem_total in the way you need
21:21 Ryan_Lane hahaha
21:21 notbmatt it'd be like six lines of code
21:22 Ryan_Lane that's crazy :)
21:22 shaggy_surfer joined #salt
21:22 * notbmatt shrugs
21:23 Ryan_Lane I'll just tell people to make sure to always completely group their math expressions
21:25 utahcon ~
21:26 windoverwater left #salt
21:27 diegows joined #salt
21:30 aquinas_ joined #salt
21:31 zooz joined #salt
21:32 jY are there any good blog posts on setting up tests for state files?
21:35 CheKolyN joined #salt
21:36 smcquay joined #salt
21:37 matrix3000 joined #salt
21:38 aquinas_ joined #salt
21:39 timc3 joined #salt
21:39 bhosmer joined #salt
21:41 Ryan_Lane heh. ugh
21:41 Ryan_Lane salt-call --local != file_client: local
21:42 Ryan_Lane there's lots of checks for self.opts.get('local', False)
21:42 forrest Ryan_Lane, you should have tagged Armin in your jinja2 complaining :P
21:42 Ryan_Lane which, as you'd imagine isn't the same as file_client: local
21:42 forrest maybe he'll actually start working on it again instead of his weird command line thing
21:42 Ryan_Lane :D
21:42 Ryan_Lane doubtful
21:42 forrest yea I doubt it as well
21:42 forrest I don't even get why he is working on that
21:43 Ryan_Lane if I set local: True in the minion config, things work like they should
21:44 Ryan_Lane which is obviously not a valid configuration option
21:47 shaggy_surfer joined #salt
21:49 diegows joined #salt
21:51 ajolo__ joined #salt
21:53 shaggy_surfer joined #salt
21:54 mikber joined #salt
22:01 matrix30001 joined #salt
22:04 Ryan_Lane1 joined #salt
22:05 bigl0af_ joined #salt
22:05 tligda1 joined #salt
22:12 tligda joined #salt
22:13 funzo_ joined #salt
22:16 chiui joined #salt
22:20 Cidan joined #salt
22:20 _TheDodd_ joined #salt
22:21 ggoZ joined #salt
22:27 bhosmer joined #salt
22:27 forrest_ joined #salt
22:34 mafro joined #salt
22:35 mafro lo I’m getting a “too many open files” in bundled/zeromq/src/ipc_listener.cpp:200
22:35 mafro and then an abort core dumped
22:35 mafro which leaves my master completely dead
22:35 mafro running 2014.1.4 on Ubuntu precise, with only 8 accepted minions
22:37 Joseph mafro: hmm that doesn't sound good
22:37 mafro Joseph: agreed.. this master is actually in the process of being replaced - I just didnt want to have to do it today
22:38 mafro and really, this shouldnt be happening
22:38 Joseph exhausting file descriptors can theoretically happen if there are enough minions and enough jobs run cause each job has a set of files in the job cache directory
22:39 Joseph if you "rm -rf /var/cache/salt/master/*"
22:39 Joseph does the problem still occur?
22:42 tligda joined #salt
22:42 fragamus joined #salt
22:42 mafro Joesph: yes, just tried
22:42 mafro it’s a pain because I have manually kill all the orphaned salt-master processes!
22:44 mafro ah a quick google - pkill -f
22:47 jtang1 joined #salt
22:49 joehoyle joined #salt
22:53 dsolsona joined #salt
22:54 mateoconfeugo joined #salt
22:55 Luke joined #salt
22:55 DaveQB joined #salt
22:56 thedodd joined #salt
22:57 BrendanGilmore joined #salt
23:02 matrix3000 joined #salt
23:05 jdmf joined #salt
23:05 jeffrubic joined #salt
23:06 napper joined #salt
23:12 bhosmer joined #salt
23:12 Outlander joined #salt
23:15 teskew joined #salt
23:20 Luke joined #salt
23:27 TyrfingMjolnir joined #salt
23:41 conan_the_destro joined #salt
23:42 dsolsona joined #salt
23:46 mosen joined #salt
23:47 ipalreadytaken joined #salt
23:49 joehoyle joined #salt

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