Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2015-04-27

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

All times shown according to UTC.

Time Nick Message
00:05 JDiPierro joined #salt
00:09 solidsna_ joined #salt
00:12 zekoZeko anyone trying to manage LXC containers on Debian 8 with Salt 2014.7? I can create/start/stop the containers, but salt.bootstrap fails...
00:17 aawerner joined #salt
00:17 blacked joined #salt
00:18 timoguin joined #salt
00:19 aquassaut joined #salt
00:25 TyrfingMjolnir joined #salt
00:27 pdayton joined #salt
00:35 amcorreia_ joined #salt
00:46 juanito joined #salt
00:51 vschum1 joined #salt
00:57 c10 joined #salt
00:59 ajw0100 joined #salt
01:01 vschum1 joined #salt
01:01 michelangelo joined #salt
01:01 zircote joined #salt
01:01 zircote joined #salt
01:04 ninkotech__ joined #salt
01:13 johnzorn joined #salt
01:16 rosenfs joined #salt
01:19 ninkotech__ joined #salt
01:19 Georgyo joined #salt
01:20 _Cyclone_ joined #salt
01:20 Laogeodritt joined #salt
01:21 copelco joined #salt
01:22 lkannan_ joined #salt
01:22 bbhoss joined #salt
01:22 adrianhannah joined #salt
01:22 zipkid joined #salt
01:22 JonGretar joined #salt
01:23 fxdgear joined #salt
01:26 MatthewsFace joined #salt
01:27 ninkotech__ joined #salt
01:28 yomilk joined #salt
01:32 MaliutaLap left #salt
01:35 hemphill joined #salt
01:38 Ahlee joined #salt
01:47 ilbot3 joined #salt
01:47 Topic for #salt is now Welcome to #salt | 2014.7.5 is the latest | Please use https://gist.github.com for code, don't paste directly into the channel | Please be patient when asking questions as we are volunteers and may not have immediate answers | Channel logs are available at http://irclog.perlgeek.de/salt/
01:47 TyrfingMjolnir joined #salt
01:49 bhosmer joined #salt
01:50 aawerner joined #salt
01:50 pdayton joined #salt
01:50 JDiPierro joined #salt
01:53 aparsons joined #salt
01:58 jonlangemak joined #salt
02:01 ITChap joined #salt
02:02 aparsons joined #salt
02:07 ninkotech__ joined #salt
02:08 malinoff joined #salt
02:18 solidsnack joined #salt
02:20 aparsons joined #salt
02:30 pipeep joined #salt
02:37 pdayton joined #salt
02:40 blacked joined #salt
02:45 badon joined #salt
02:45 donmichelangelo joined #salt
02:46 c10 joined #salt
02:46 __71nch0__ joined #salt
02:47 __71nch0__ Hello! Does anybody have a good pillar salt-cloud example?
02:47 __71nch0__ Official docs are mostly for cloud.profiles.d and cloud.providers.d
02:47 __71nch0__ I'd like to have them on my pillar files, as they are distributed on a git repo
02:48 favadi joined #salt
02:50 clintberry joined #salt
03:00 fusionx86 joined #salt
03:00 ITChap joined #salt
03:02 jtanner joined #salt
03:05 evle joined #salt
03:11 Furao joined #salt
03:15 cztanu Say for example you set up an environment with salt master + a couple of minions, then shut the entire thing down for a couple of weeks... Would this cause any problems? I ask this even though I already know, there are definitely problems with my setup. Nothing really in the logs either.
03:34 rdas joined #salt
03:36 zach left #salt
03:39 davisj joined #salt
03:45 Furao joined #salt
03:50 bhosmer_ joined #salt
03:51 pdayton joined #salt
03:52 radd joined #salt
03:54 mosen joined #salt
03:58 bbradley joined #salt
04:09 timoguin joined #salt
04:16 scoates joined #salt
04:20 solidsnack joined #salt
04:24 clintberry joined #salt
04:25 clintberry joined #salt
04:33 radd joined #salt
04:35 c10 joined #salt
04:42 yexingok joined #salt
04:44 yexingok joined #salt
04:57 cberndt joined #salt
05:19 blacked joined #salt
05:21 otter768 joined #salt
05:26 thayne joined #salt
05:26 kuromagi joined #salt
05:36 c10 joined #salt
05:40 baweaver joined #salt
05:41 rdas_ joined #salt
05:42 ageorgop joined #salt
05:46 baweaver joined #salt
05:48 rdas_ joined #salt
05:49 krelo joined #salt
05:49 blacked joined #salt
05:50 baweaver joined #salt
05:50 bhosmer_ joined #salt
05:55 JayFK joined #salt
05:56 qybl_ joined #salt
05:56 qybl joined #salt
06:02 AndreasLutro joined #salt
06:08 stoogenmeyer joined #salt
06:15 whytewolf clear
06:15 whytewolf damn it wrong tab
06:16 iggy cztanu: should work fine as long as you bring everything back up in the right order
06:16 ktosiek joined #salt
06:24 jxm_ joined #salt
06:24 jay_d joined #salt
06:24 LinuxHorn joined #salt
06:25 akitada joined #salt
06:28 Grokzen joined #salt
06:29 harkx any saltpad users around? :) I've just installed, following the readme in virtualenv, get the login screen but after logging in it returns me to login screen without error (user/pass exists) . Any idea how to troubleshoot this further?
06:31 NixNull joined #salt
06:32 NixNull left #salt
06:35 SpX joined #salt
06:35 flyboy joined #salt
06:35 iggy test logging into salt-api with curl (there's examples in the docs iirc)
06:37 TyrfingMjolnir joined #salt
06:41 jvblasco joined #salt
06:43 c10 joined #salt
06:44 jvblasco joined #salt
06:45 jvblasco joined #salt
06:45 jeddi joined #salt
06:46 Auroch joined #salt
06:48 harkx iggy, okay, will do that, salt-api logging, thanks!
06:48 nene hi.. i wrote one sample sls for mysql.. How can i tell my mysqld daemon to restart if config file changes?
06:53 whytewolf nene: if make sure the config file is also controlled by salt using file.managed state and use watch in in a service.running state. http://docs.saltstack.com/en/latest/ref/states/requisites.html
06:57 jvblasco joined #salt
06:57 nene whytewolf: thanks
06:59 whytewolf nene: no problem
07:03 magnus-lycka joined #salt
07:04 eseyman joined #salt
07:06 iggy harkx: I meant login... not logging
07:06 mage_ joined #salt
07:06 lb1a joined #salt
07:07 Hell_Fire joined #salt
07:08 c10 joined #salt
07:09 denys joined #salt
07:09 jcockhren ?quit
07:10 harkx iggy, yeah, figured that out, no problem, will try that
07:12 toanju joined #salt
07:14 stoogenmeyer_ joined #salt
07:19 blacked joined #salt
07:22 otter768 joined #salt
07:27 JlRd joined #salt
07:33 asido joined #salt
07:34 CeBe joined #salt
07:43 Auroch joined #salt
07:44 Grokzen joined #salt
07:49 linjan joined #salt
07:49 Romlok joined #salt
07:50 pf_moore joined #salt
07:51 bhosmer_ joined #salt
07:53 ndrei joined #salt
07:55 blacked joined #salt
08:01 subsignal joined #salt
08:01 mkropinack joined #salt
08:04 Furao joined #salt
08:05 tr_h joined #salt
08:11 chiui joined #salt
08:11 kuromagi joined #salt
08:18 hardwire joined #salt
08:21 Xevian joined #salt
08:34 dramagods joined #salt
08:43 jrluis joined #salt
08:47 al joined #salt
08:48 magnus-lycka joined #salt
08:50 teogop joined #salt
08:58 N-Mi joined #salt
08:58 N-Mi joined #salt
08:58 lothiraldan joined #salt
09:06 bluenemo joined #salt
09:07 blacked joined #salt
09:10 ndrei joined #salt
09:11 mage_ I have a question on how to organize things, I plan to use salt to deploy various small webapps (python, virtualenv, dedicated user, ...) and I wonder how would you organize things as I would like to be able to redeploy from scratch but also only regenerate the virtualenv for example for a dedicated webapp .. so one sls per webapp or one sls for all users, one for all venvs, etc .. ?
09:11 mage_ are there guidelines for this ?
09:13 riftman joined #salt
09:14 KoFFiE joined #salt
09:15 harkx mage_, i have a similar "issue" and our rewrite of our sls files is going to be very modular and using grains on pillar to "assign" roles to minions
09:15 harkx mage_, also some info over here: http://docs.saltstack.com/en/latest/topics/best_practices.html
09:17 mage_ I planned for example to do one file per user, then a users/webapp/top.sls with includes, same for venvs, etc
09:18 mage_ I'll read the best practices .. thanks !
09:18 o5k joined #salt
09:18 c10 joined #salt
09:21 linjan joined #salt
09:29 ITChap joined #salt
09:29 bhosmer_ joined #salt
09:30 bhosmer__ joined #salt
09:36 Not_ joined #salt
09:37 lothiraldan joined #salt
09:40 peters-tx joined #salt
09:46 gwmngilfen joined #salt
09:48 linjan joined #salt
09:51 [M7] joined #salt
09:54 kaos01 joined #salt
09:57 slav0nic joined #salt
10:11 toanju joined #salt
10:15 riftman joined #salt
10:19 renat joined #salt
10:21 CedNantes joined #salt
10:21 CedNantes hi
10:22 renat Hello! Saltstack can use local repositories like: deb ftp://apt-srv/repo /  ?
10:24 lothiraldan joined #salt
10:29 CedNantes renat : https://github.com/saltstack/salt/issues/14357
10:29 losh joined #salt
10:30 catpig joined #salt
10:37 giantlock joined #salt
10:38 wnkz joined #salt
10:39 magnus-lycka joined #salt
10:39 gwmngilfen joined #salt
10:42 _Cyclone_ joined #salt
10:52 ujjain- joined #salt
11:01 [1]Dom joined #salt
11:13 riftman joined #salt
11:13 toanju joined #salt
11:14 ndrei joined #salt
11:15 harkx good news, salt-api connection with curl works but the saltpad login does not (Authentication failure of type "token" occurred for user xxx)
11:15 Grokzen what session backend are you using for the api?
11:16 Grokzen if you have some webserver in front of the api you need something like memcached for sessions to work across multiple requests :P
11:19 denys joined #salt
11:24 otter768 joined #salt
11:29 harkx no webserver yet, just saltpad, both salt master, salt api, saltpad are running on the same host (rest_cherrypy configured in the master config file)
11:29 harkx the curl way does work, also with multiple requests
11:29 Grokzen oki, i got the problem with file based session storage with the api and memcached was the only way to fix it :P
11:30 Grokzen file or in memory cache i should say
11:30 harkx okay, good to know
11:30 Grokzen file locking was a big issue with cherrypy and it did not release them and was throwing exceptions all over the place
11:31 harkx brrr :)
11:35 bhosmer joined #salt
11:36 renat CedNantes Thanks, but I need install deb packages from this repository, not redistribute it as regular files.
11:37 lothiraldan joined #salt
11:40 magnus-lycka joined #salt
11:51 yomilk joined #salt
11:52 illern_ joined #salt
11:53 mephx joined #salt
11:55 CeBe1 joined #salt
11:57 Guest92231 joined #salt
12:04 hasues joined #salt
12:04 xf10e joined #salt
12:04 xf10e hi everyone
12:05 magnus-lycka joined #salt
12:06 [1]Dom which version is Beryllium? :)
12:08 PL_um joined #salt
12:10 hasues left #salt
12:12 xf10e the one after 2015.2. 2015.7 or something like that
12:13 [1]Dom ah ok, so it's future version
12:13 [1]Dom just saw hp_pillar and was wondering if I can use it :)
12:13 XenophonF joined #salt
12:14 XenophonF just to be 100% perfectly clear, to use s3fs, i need to add "s3fs" to fileserver_roots and not "s3", right?
12:18 CedNantes I wanted to test the latest version so i followed http://docs.saltstack.com/en/latest/topics/releases/releasecandidate.html but how can i add salt-cloud support to the installation ?
12:20 XenophonF just found a bug report with a sample s3fs config (https://github.com/saltstack/salt/issues/23016), and it looks like "s3fs" is indeed the correct setting
12:20 aquassaut joined #salt
12:21 xf10e [1]Dom: /might/ be backported to 2015.2 or even 2014.7. you can grab the module from github and test it on your current setup. if it just needs minor or even no fixes it might show up in later versions of pre-beryllium releases.
12:22 [1]Dom @xf10e: Thanks!
12:22 [1]Dom is it a good practice to store pillars in hg or git lets say in bitbucket or github private repositories?
12:23 JDiPierro joined #salt
12:24 c10 joined #salt
12:24 babilen [1]Dom: You might want to consider the gpg renderer or something like blackbox (→ https://github.com/StackExchange/blackbox ) for that
12:25 volongato joined #salt
12:25 babilen I wouldn't necessarily keep sensitive data anywhere but on infrastructure I control (and also don't like the idea of a bazillion people running around with private keys, certificates, ... on their laptops)
12:27 [1]Dom I agree, I was considering to set up a hardened machine inside the infrastructure to host such mercurial repository, that way I can control who and why do they have access to it
12:27 cberndt joined #salt
12:28 babilen That's more or less what we do (s/mercurial/git)
12:29 babilen The GPG renderer comes in handy as well. I have not played with blackbox yet and would be interested to hear about experiences with that.
12:29 babilen One problem with the gpg renderer is that it uses considerably more resources than "plain" pillars
12:32 Wout joined #salt
12:34 OnTheRock joined #salt
12:37 Wout Hello everyone; I am new to Salt. I am trying to add a zypper repository to a SUSE Linux Enterprise Server installation using pkgrepo.managed and just got a seg fault.
12:37 Wout I was wondering how you would investigate the problem
12:37 Wout The SLS looks like this: https://gist.github.com/anonymous/fab68f661f39f02da972
12:39 lothiraldan joined #salt
12:39 cmcmacken joined #salt
12:40 dendazen joined #salt
12:40 cberndt joined #salt
12:41 Vr-Jack Wout: run salt-call on minion in foreground with debug enabled; probably.
12:44 _prime_ joined #salt
12:46 Wout I am still running masterless, with: salt-call --local state.highstate -l debug
12:46 Wout The last log message before "Segmentation fault" is: "[INFO    ] Executing state pkgrepo.managed for devel:tools:compiler.repo"
12:47 Vr-Jack Is devel:tools:compiler.repo a valid repo name?
12:49 JlRd joined #salt
12:50 denys joined #salt
12:50 Wout yes
12:51 bhosmer joined #salt
12:51 Wout Colons and dots are allowed in repo names; the repo URL is http://download.opensuse.org/repositories/devel:/tools:/compiler/SLE_11_SP3/
12:51 zekoZeko why do i always get a change when i have service.running: - enable: True ?
12:52 zekoZeko postfix formula does this for instance
12:52 zekoZeko would be better to have both a service.enabled and service.running states?
12:55 evle1 joined #salt
12:58 subsignal joined #salt
12:59 renat Hi! I get error  SystemError: E:The value 'wheezy' is invalid for APT::Default-Release as such a release is not available in the sources when run on master  salt '*' pkg.install <package>
13:00 renat But on minion installation done well. It is cache issue or something other?
13:01 linjan joined #salt
13:02 magnus-lycka joined #salt
13:03 FeatherKing joined #salt
13:04 riftman joined #salt
13:06 LtLefse zekoZeko: if you run "service postfix status ; echo $?" do you get 0?
13:06 fxhp joined #salt
13:06 jdesilet joined #salt
13:06 LtLefse if not, salt will think it's not running and try to start it again each time
13:07 stoogenmeyer__ joined #salt
13:08 zekoZeko LtLefse: it does.
13:08 pdayton joined #salt
13:11 renat For example salt-call --local pkg.install mc
13:12 asaladin joined #salt
13:12 LtLefse zekoZeko: is anything else changing that would trigger a postfix restart?
13:13 zekoZeko nope
13:13 zekoZeko just that state
13:14 zekoZeko it says changed: 1 on the end of the salt run (or even state.sls postfix run)
13:14 Wout Vr-Jack: would you recommend filing a bug report?
13:14 perfectsine joined #salt
13:15 LtLefse zekoZeko: I guess run "salt-call -l debug state.sls your-postfix-state" and see what exact command the minion is running the check the status of postfix
13:16 shorty_mu joined #salt
13:17 zekoZeko ok thanks, will try that.
13:18 zekoZeko otoh service.running is enough for me, it's enabled by default on install so I can leave it out for now if I can't fix it.
13:18 scoates joined #salt
13:19 LtLefse oh, it's the 'enabled' bit causing the changes?
13:22 shorty_mu Hi all, I'm trying to get Elasticsearch running as master_job_cache and am stuck. Config and error can be found in the Gist: https://gist.github.com/bemeyert/ab3d0567d953d154a9d4  Version is 2014.7.5 and the es mdoule has been install via pip. Can anybody help me? Cheers
13:22 zekoZeko LtLefse: [DEBUG   ] output: Failed to get unit file state for postfix.service: No such file or directory
13:22 zekoZeko LtLefse: it seems it's a problem because there's no systemd unit for postfix, it's using an init script
13:23 linjan joined #salt
13:23 Deevolution joined #salt
13:23 LtLefse ah, okay. I haven't taken the systemd plunge yet
13:23 zekoZeko i did, yesterday :) installed Jessie on another LV and booted to that, put old install in a container and move stuff off it slowly :)
13:24 zekoZeko and moving to salt.
13:25 Furao joined #salt
13:25 otter768 joined #salt
13:26 LtLefse yeah, I guess like you said, just leave it out if you don't need it
13:27 zekoZeko except that means changing the formula... bah. I'll report a bug.
13:28 LtLefse excellent, blaze that trail for the rest of us ;)
13:30 AndreasLutro zekoZeko: systemd should provide perfect backwards compatibility with openrc init scripts
13:31 Vr-Jack Wout: best option, probably. You might try another repo for testing what doesn't have : in it. I'm wondering if something is getting misinterpreted in the layers.
13:31 fusionx86 joined #salt
13:32 Vr-Jack or perhaps use some quotes. worth a try. definitely a weird issue
13:32 zekoZeko AndreasLutro: agreed.
13:34 Tecnico1931 joined #salt
13:35 AndreasLutro zekoZeko: sorry I worded that wrong. systemd DOES provide backwards compatibility, so if postfix has an init script and you're getting that error something is wrong
13:36 LtLefse AndreasLutro: does that include backward compat for the method of installing/enableing that init script (e.g. chkconfig)?
13:36 LtLefse because that's where zekoZeko is having the issue
13:36 bhosmer joined #salt
13:36 AndreasLutro yeah, at least on debian jessie that stuff has worked flawlessly for me
13:37 Wout Vr-Jack: Thanks for your help,  I'll file a bug report
13:38 xMopxShell joined #salt
13:39 samnmax joined #salt
13:39 pcn Quick stupid question about the docs: http://docs.saltstack.com/en/latest/topics/jobs/index.html in states says that the shell is "\bin\sh" and I'm hoping that's a mistake in trying to quote "/bin/sh" or something and not some odd convention for slashes in salt?
13:41 LtLefse shell: /bin/bash in all my states
13:41 pcn kthanks
13:42 GnuLxUsr joined #salt
13:42 markm joined #salt
13:42 garphy`aw joined #salt
13:43 xf10e joined #salt
13:44 zekoZeko i added a comment here: https://github.com/saltstack/salt/issues/18311
13:44 zekoZeko systemd is-enabled does not work with init scripts.
13:45 _mel_ joined #salt
13:45 SaveTheRbtz joined #salt
13:46 zekoZeko oh, and https://bugs.debian.org/705254
13:47 Tyrm joined #salt
13:48 mpanetta joined #salt
13:48 _mel_ Hi. i have 80 minions. if i run a cmd.run on all of them, only a few get an answer. i've already raised the worker_threads to 32
13:49 LtLefse _mel_: salt version?
13:49 Grokzen joined #salt
13:49 _mel_ 2014.7.2+ds-1~bpo70+1
13:50 LtLefse I had that problem on 2014.7.1 and "solved" it by raising worker_threads >= number of minions :\
13:50 _mel_ but that means > 80 procs running, right?
13:50 echo joined #salt
13:51 LtLefse right. doesn't scale
13:51 babilen _mel_: Are you sure that only a few reply or are you simply running into the shell timeout?
13:51 riftman joined #salt
13:51 babilen Have you checked "salt-run jobs.lookup_jid JID_OF_THE_JOB" ?
13:51 _mel_ tahts what i run: salt '*' cmd.run "[ -f /opt/scripts/autopostgresqlbackup.sh ] && grep 'POSTBACKUP=' /opt/scripts/autopostgresqlbackup.sh"
13:52 _mel_ is there a "global" timeout that i should raise?
13:53 babilen That looks like a job that might take quite some time. How do you determine that "only a few get an answer" ? What are the *exact* symptoms you see? (are the commands not executed at all, do you get an error in salt, are you simply not given feedback on the shell (but the job continues to run, .... ?)
13:53 StDiluted joined #salt
13:53 babilen )
13:54 bbhoss joined #salt
13:55 _mel_ the exact symptons so far are, that i only have about 30 minions who give an empty return or print the line that i search
13:55 babilen What about the others?
13:55 _mel_ thsta my question :-)
13:56 _mel_ thats ..
13:56 babilen So, have you checked "salt-run jobs.lookup_jid JID_OF_THE_JOB" ? What about "salt-run jobs.active" ?
13:58 timoguin joined #salt
13:59 _mel_ there is one state.highstate running
13:59 andrew_v joined #salt
13:59 CedNantes anyone here tried salt-pad ?
13:59 _mel_ http://pastebin.com/DzBM4pSt
13:59 funzo joined #salt
14:00 magnus-lycka joined #salt
14:00 jerematic joined #salt
14:00 dendazen I have this puppet variable i define i am trying to convert to salt http://pastebin.com/0P6TH6Ci Is there a way in salt i can do something like {% set app_server  if grains['fqdn'] = ^(backtest|dev|uat|nextgen) %}?
14:02 kawa2014 joined #salt
14:03 babilen _mel_: What about your other job? What's the output if you run "salt-run jobs.lookup_jid JID_OF_THE_JOB" ? (you naturally have to replace JID_OF_THE_JOB with the job id in question)
14:04 _mel_ the jobs.active is now empty. i'll start the job again
14:04 o5k joined #salt
14:04 _mel_ i've modified the command to exclude windows server: salt -C 'G@kernel:Linux' cmd.run "[ -f /opt/scripts/autopostgresqlbackup.sh ] && grep 'POSTBACKUP=' /opt/scripts/autopostgresqlbackup.sh"
14:05 bhosmer joined #salt
14:06 ek6 joined #salt
14:07 _mel_ the output: http://pastebin.com/fXhpr6ki . jobs.active is empty
14:08 _mel_ the same with test.ping: http://pastebin.com/Hd2hLJJy
14:09 Ssquidly joined #salt
14:10 babilen Use a better pastebin such as http://refheap.com or https://gist.github.com rather than pastebin.com
14:10 babilen Make the web a better place!
14:13 babilen _mel_: Okay, could you run that job with "-v" or set show_jid to True in the master configuration (you might want to set "ping_on_rotate: True" and "state_output: changes" while you are at it)
14:13 babilen That should give you the jid and then you can investigate in more detail. You might also want to check one of the minions that don't return for errors/information in their /var/log/salt/minion
14:15 favadi joined #salt
14:16 _mel_ ok
14:17 adelcast left #salt
14:18 edrocks joined #salt
14:18 drawsmcgraw joined #salt
14:21 markm joined #salt
14:21 babilen _mel_: I'd also be interested in the output of simply "grep 'POSTBACKUP=' /opt/scripts/autopostgresqlbackup.sh" (i.e. without the conditional)
14:22 lictor36 joined #salt
14:23 perfectsine joined #salt
14:23 _mel_ here it is: http://pastebin.com/tTZ1f9re
14:24 babilen pastebin.com
14:24 drawsmcgraw Signal boost: I asked the Saltstack subreddit how they document their states: http://www.reddit.com/r/saltstack/comments/3416me/salt_state_catalog/
14:24 keimlink joined #salt
14:24 drawsmcgraw Feel free to chime in. (in fact, plz chime in :D   )
14:25 _mel_ and the job lookup: http://pastebin.com/X990sh5K
14:25 babilen _mel_: Which salt version is that?
14:25 robothands we dont use documentation
14:25 * babilen will not open anymore pastebin.com
14:25 babilen drawsmcgraw: I generate it with sphinx
14:25 ageorgop joined #salt
14:25 _mel_ i'll delete the not connected minnions
14:26 drawsmcgraw babilen: That's exactly what my ponies & unicorns scenario is! I wasn't aware Sphinx could do that with a state tree
14:26 Romlok babilen: did pastebin.com eat your hamster?
14:27 hellome joined #salt
14:27 drawsmcgraw babilen: Can I just follow the standard Sphinx docs and it'll work or did you do something in particular to make it document your state tree?
14:28 babilen Romlok: It is simply an ad-laden, ugly website that is meant to generate revenue from traffic by the great unwashed (i.e. people who simply google "pastebin" and don't know better)
14:29 dramagods joined #salt
14:29 babilen drawsmcgraw: I have written documentation in sphinx (well, RST) and document it much like the salt project documents states and modules. I don't include SLS files (yet)
14:29 jcockhren sphinx++
14:29 dyasny joined #salt
14:30 drawsmcgraw babilen: Ah, I see. So you don't have Sphinx ingest the contents of your state tree, you're just diligent about keeping up with your documentation?
14:30 jcockhren I think the saltstack team should release their a couple of their custom sphinx extensions
14:30 babilen There might be an "autodoc like" way to generate it from SLS files, but so far it is simply documentation living in doc/ that is manually maintained and I only use autodoc for Python code (i.e. _module/*)
14:30 babilen jcockhren: YES
14:30 _mel_ babilen: version is 2014.7.2+ds-1~bpo70+1
14:30 shorty_mu left #salt
14:31 babilen oh, yes, please
14:31 babilen _mel_: That version had issues such as the one you are seeing. Could you run the latest?
14:31 Romlok hmm, fairly ugly, sure, but even with js on it doesn't seem that bad to me
14:31 drawsmcgraw Interesting. Alright, thanks babilen!
14:31 _mel_ babilen: that would be 2014.7.5+ds-1~bpo70+1, right?
14:32 _mel_ should i stop all minions before the update?
14:32 gladiatr joined #salt
14:34 dendazen Can i create  a pillar based on regex?
14:34 babilen _mel_: Indeed, no need to stop them. A simple "salt '*' pkg.install salt-minion refresh=True" should suffice. (update the master first)
14:35 magnus-lycka joined #salt
14:36 babilen dendazen: What do you mean by that?
14:36 zekoZeko i'm fixing Debian's update-rc.d right now... have to add is-enabled/is-disabled commands for systemd compatibility.
14:36 dendazen I mean i need to assign a pillar to a minion based on regex in its hostname.
14:37 zekoZeko what must I check? I don't think all runlevel links are important, I guess I should only check /etc/rc2.d (default runlevel in debian)?
14:37 dendazen and then filter by it in jinja
14:37 derelm joined #salt
14:37 dendazen since jinja syntax if/elif/else is limited fore regex matching, i want to do the logic somewhere else.
14:38 huddy joined #salt
14:39 ALLmightySPIFF joined #salt
14:39 babilen dendazen: Do it in the top.sls of the pillar: http://docs.saltstack.com/en/latest/topics/targeting/compound.html
14:39 iggy ^
14:39 dendazen so i would set pillars for each particular match i would need and then do conditional on it in jinja template
14:40 denys joined #salt
14:40 iggy always use top file for assignment unless it's just absolutely impossible
14:40 dendazen main top.sls or pillar top.sls?
14:40 iggy I hate looking at a formula and it's like {% if use_ppa %}... you should have a separate state that assigns the ppa states
14:41 rojem joined #salt
14:41 iggy you said pillar, so...
14:41 dendazen ok
14:41 dendazen let me try, it is such pita jinja doesn’t support regex
14:42 ALLmightySPIFF joined #salt
14:44 Vr-Jack iggy: on the other hand, it's annoying that there's not an easy way to track current states cross minion.
14:44 _mel_ babilen: is there an updated  squeeze version too?
14:45 Vr-Jack best I've come up with is setting watch states that event.send and reactor to update a pillar states file
14:46 debian112 joined #salt
14:46 c10 joined #salt
14:46 ajw0100 joined #salt
14:47 cptsupermrkt joined #salt
14:47 adelcast1 joined #salt
14:48 Brew joined #salt
14:49 jonlangemak joined #salt
14:53 MSeven joined #salt
14:53 Vr-Jack of course, one could argue that highstate isn't the place to do orchestration tasks, but strictly to maintain them.
14:54 [7hunderbird] joined #salt
14:54 mnml_ joined #salt
14:55 spiette joined #salt
14:56 Auroch joined #salt
14:57 riftman joined #salt
14:57 smcquay joined #salt
14:58 _mel_ babilen: i raised th timeout from 5 to 60 seconds. now every server seems to respond
14:58 clintberry joined #salt
15:02 cornfeedhobo left #salt
15:04 jonlangemak left #salt
15:08 thayne joined #salt
15:11 sandah joined #salt
15:11 scbunn joined #salt
15:12 magnus-lycka joined #salt
15:13 iggy Vr-Jack: yeah... salt has an orchestrate runner for orchestration
15:16 kbyrne joined #salt
15:16 Vr-Jack iggy: yeah. I've debated just dividing out my workflows. orchestrate all installs so I get the master level dependencies and then only maintain the smaller stuff (config files/restarts) from highstate
15:17 iggy we're trying to move to only use orchestrate minimally and just break everything down to pieces that aren't so inter-dependent
15:18 Vr-Jack I maintain a lot of cross server dependencies
15:18 iggy but all the code is our own, so it's possible for us to do that
15:18 iggy if you were using stuff that you didn't own, I could see that being a tougher sell (if not impossible)
15:18 Vr-Jack from simple things such as ntp/dns servers to database credentials prior to app access, etc
15:21 Vr-Jack Well, I could always setup an ISP server with every service running on bare metal, but there are advantages to isolating all the services and interconnecting the vms
15:21 _prime_ joined #salt
15:21 _prime__ joined #salt
15:25 _prime_ joined #salt
15:26 otter768 joined #salt
15:27 hax404 joined #salt
15:27 kawa2014 joined #salt
15:27 redzaku joined #salt
15:28 Furao joined #salt
15:29 iggy what I'm saying is, your services should be able to run like normal on their own
15:30 kawa2014 joined #salt
15:30 magnus-lycka joined #salt
15:36 jalbretsen joined #salt
15:37 bhosmer_ joined #salt
15:40 Furao joined #salt
15:41 aparsons joined #salt
15:43 rm_jorge joined #salt
15:45 krobin joined #salt
15:46 Guest70 joined #salt
15:46 conan_the_destro joined #salt
15:51 SeeDickCode joined #salt
15:52 UtahDave joined #salt
15:55 kunersdorf joined #salt
15:57 Vr-Jack iggy: definitely. there's only a few minor things I can think of that would fail hard. usually, initial database setup/permissions for an app, ntp, dns. Those things should probably be done via orchestration anyways, as they are one time dependencies and then everything runs normal.
15:59 iggy if you order your top.sls correctly, that should take care of most of your ordering
15:59 radd joined #salt
16:00 gwmngilfen joined #salt
16:00 Vr-Jack as long as I don't do automated highstate schedules
16:01 Vr-Jack from what I could tell, the scheduling is minion driven
16:01 iggy I say all of this in a perfect world
16:02 Vr-Jack well, I'm still new to salt, so if I missed something like a master schedule, you'd have to tell me. :)
16:02 iggy the truth of the matter is we have some nasty dependencies between our services that are so heinous we still have to do some of the interdependencies by hand
16:03 iggy but we're working toward getting everything broken up and not dependent on other stuff
16:05 Vr-Jack If I hit a really bad circular dependency, I was thinking of just doing an event.send base done a state condition, then updating a pillar with the state info from reactor. Lack of state info is presumed to be down/failed/no state for things that depend on it.
16:05 viq_ joined #salt
16:05 linjan joined #salt
16:13 Tyrm_ joined #salt
16:16 VR-Jack2 joined #salt
16:18 aparsons joined #salt
16:20 baweaver joined #salt
16:21 druonysus joined #salt
16:21 druonysus joined #salt
16:21 spookah joined #salt
16:23 StDiluted joined #salt
16:26 bluenemo joined #salt
16:27 rhand joined #salt
16:27 sroegner joined #salt
16:27 JDiPierro joined #salt
16:28 rojem joined #salt
16:32 KyleG joined #salt
16:32 KyleG joined #salt
16:33 ckao joined #salt
16:36 desposo joined #salt
16:37 sroegner joined #salt
16:37 MatthewsFace joined #salt
16:38 thayne joined #salt
16:39 Gareth morning morning
16:41 fusionx86 left #salt
16:43 TyrfingMjolnir joined #salt
16:43 adelcast1 good morning, last week I was looking at beacons and engines, they look like very interesting technologies
16:44 adelcast1 however, I am not sure when is preferred to use one over the other
16:44 manfred beacons run on the minion
16:44 manfred engines run on the master
16:44 adelcast1 oh,  I thought engines could also run on the minion
16:44 Gareth depends on the use case.  beacons are useful for monitoring things on the minion and causing something to happen.  engines are long running tasks that run on the master.
16:44 manfred pretty sure engines are like salt-run and run on the master
16:45 renat Hi! I get error  SystemError: E:The value 'wheezy' is invalid for APT::Default-Release as such a release is not available in the sources when run on master  salt '*' pkg.install <package>.
16:45 adelcast1 ok, so if they were never intended to run on the minion, that's my answer, =)
16:45 renat But on minion installation done well. It is cache issue or something other? Any help are welcome
16:46 adelcast1 I want to monitor a few properties on my target (embedded), so beacons look like a good fit...however my understanding is that beacons poll, and in my case it would be better if I could get a notification right away, instead of waiting for the poll
16:47 ark_kwag joined #salt
16:47 adelcast1 I mean, there are a few properties that I do want to poll, in which case beacons are the answer, but there are a few others that I would like to get events when they change
16:48 manfred adelcast1: that depends on how the beacon is written i think.
16:48 manfred adelcast1:  https://github.com/saltstack/salt/blob/develop/salt/beacons/inotify.py the inotify one I think is constantly watching for events iirc
16:49 manfred *maybe
16:51 manfred nm, looks like it only can poll
16:51 manfred Optionally, a beacon can be run on an interval other than the default loop_interval, which is typically set to 1 second.
16:51 baweaver_ joined #salt
16:53 Guest70 joined #salt
16:54 adelcast1 manfred: I see, thanks....would be cool if engines could run on the minion too (having a long running task on the minion that could listen for external events)
16:55 linjan joined #salt
16:56 zekoZeko there, about my previous trouble: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705254#31
16:57 zekoZeko just a proff of concept, but I'm sure it will be included when it's finished.
17:01 XenophonF joined #salt
17:04 wt joined #salt
17:04 lnr joined #salt
17:05 lnr joined #salt
17:05 lnr joined #salt
17:06 theologian joined #salt
17:09 stoogenmeyer__ joined #salt
17:11 lnr joined #salt
17:11 lnr joined #salt
17:12 lnr joined #salt
17:12 lnr joined #salt
17:12 lnr joined #salt
17:13 lnr joined #salt
17:13 lnr joined #salt
17:13 lnr joined #salt
17:14 lnr joined #salt
17:14 lnr joined #salt
17:14 lnr joined #salt
17:15 lothiraldan joined #salt
17:15 lnr joined #salt
17:15 lnr joined #salt
17:16 hemphill joined #salt
17:16 TheRealBill joined #salt
17:17 aravind joined #salt
17:17 iggy adelcast1: if you have a process that already watches for those events, just get it to start firing reactor events when things change
17:19 ksalman joined #salt
17:20 voxxit joined #salt
17:20 adelcast1 iggy: we currently created a process that does just that....but where wondering if there was something built-in with Salt that could help us ditch that process
17:21 adelcast1 iggy: our current solution somehow sounds hacky
17:21 iggy sounds legitimate to me
17:22 iggy beacons are just a shortcut for things that poll
17:23 iggy I want to say this use case was even mentioned at saltconf and calling reactors (via cmd line or salt-api) was mentioned as a valid solution
17:24 adelcast1 ok, good to know....then having a "monitoring process" that creates reactor events in the case some properties change is a valid solution to our problem
17:24 iggy at least for now... who knows, maybe they'll have something in the long run
17:24 iggy (and making minion reactors do useful things on the master was mentioned as a future TODO... which would allow engines running on the minion iiuc)
17:26 ajw0100 joined #salt
17:27 adelcast1 minon reactors are scripts that respond to events on the minion side I suppose? how do they enable engines?
17:27 otter768 joined #salt
17:29 paha joined #salt
17:29 Guest70 joined #salt
17:30 Paul_ joined #salt
17:30 Paul_ Hi
17:30 keimlink_ joined #salt
17:33 Paul_ I'm testing salt right now and have problem installing deb package on a minion. Here is my simple state file
17:33 Paul_ install_esearch:   pkg.installed:     - sources:        - elasticSearch: salt://repo/elasticsearch-1.5.1.deb
17:33 Paul_ the deb package is downloaded from elasticsearch website
17:34 Paul_ the master always report installation failed even I checked the minion, the package was indeed installed, can anyone help?
17:34 solidsnack joined #salt
17:35 Paul_ I'm using salt vesion 2014.7.5
17:35 D-Spair left #salt
17:38 UtahDave Paul_: can you pastebin the output you're getting on the command line?
17:38 bhosmer_ joined #salt
17:39 enarciso joined #salt
17:39 Paul_ sure, give me a second to re-run it
17:41 Paul_ vagrant-ubuntu-trusty-64: ----------           ID: java8     Function: pkg.installed       Result: False      Comment: The following packages failed to install/update: elasticSearch.      Started: 17:40:37.469073     Duration: 20744.886 ms      Changes:     Summary ------------ Succeeded: 0 Failed:    1 ------------ Total states run:     1
17:42 CeBe1 joined #salt
17:42 Paul_ not much info here, will printout from minion or master debug help?
17:42 blacked joined #salt
17:42 iggy can you login to the minion and run "apt-get -f install" ?
17:42 Paul_ let me try
17:44 Paul_ yes
17:44 Paul_ I can do that
17:45 Paul_ and here is the print out ==========
17:45 Paul_ sudo apt-get -f install  Reading package lists... Done Building dependency tree        Reading state information... Done 0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
17:45 Paul_ =========
17:45 druonysus joined #salt
17:46 iggy okay, there goes that theory
17:47 Paul_ and the theory is?
17:48 UtahDave Paul_: your first state you pasted in here had an id of "install_esearch" but the output you pasted showed a failure with an id of "java8"  can you use a pastebin service like pastebin.com or gist.github.com to paste your states you're trying to run?
17:49 iggy my theory was that the package wanted some dependency that was only in the elasticsearch repo
17:49 iggy have you looked at the elasticsearch-formula?
17:49 Paul_ ok, let me paste them again
17:50 UtahDave probably
17:50 Paul_ no, what is it?
17:50 chiui joined #salt
17:51 krelo joined #salt
17:51 kunersdorf does "file.managed" allow for a require?
17:51 iggy kunersdorf: everything allows require
17:52 solidsnack joined #salt
17:52 kunersdorf excellent
17:54 v0rtex Paul_: I don't know if any of what I do is useful to you but here are the relevant files for my ES setup and it works great: https://gist.github.com/ev0rtex/f128d87b06e83ffb3a2c
17:54 clintberry joined #salt
17:54 Edgan joined #salt
17:55 v0rtex Paul_: FYI, the pillar/elastic.sls file is auto-generated by a node script I wrote but you can manually fill out the necessary bits in your own pillar
17:57 Paul_ Hi, v)rtex
17:57 Paul_ Hi, v0rtex
17:57 kunersdorf iggy: do you have a example of a state require?
17:58 Paul_ here is the pastebin link
17:58 Paul_ http://pastebin.com/khUydeUh
17:59 Paul_ I'm testing run salt , just for a test, i download es deb and try to install it
17:59 Paul_ I also tried a java deb, it failed too
18:00 aparsons joined #salt
18:00 v0rtex Paul_: have you tried running with "-l debug" to see more details as to what might be happening?
18:00 kunersdorf i've tried these 2:  https://gist.github.com/kombatunit/fc6ea189cd7a9a08dcd7
18:00 iggy kunersdorf: http://docs.saltstack.com/en/latest/ref/states/requisites.html
18:00 dendazen would it be correct in pillar top.sls set variable ‘apphost’ this way? http://pastebin.com/8Mn0zBXY
18:01 Paul_ yes, I did
18:01 dendazen and then use that ‘apphost’ in jinja checking if it is ‘True’ or ‘False’.
18:01 Paul_ here are the last free line of the debug print out on the minion
18:01 Paul_ the last few lines
18:02 Paul_ http://pastebin.com/BfsPLqaZ
18:02 Paul_ not sure what happened
18:03 iggy Paul_: if you look at the example in the sources section of pkg.installed docs, the key always matches the basename of the package file... that's like that for a reason
18:03 iggy i.e. change it to "- elasticsearch: salt://repo/elasticsearch-1.5.1.deb"
18:03 jonatas_oliveira joined #salt
18:03 iggy instead of elasticSearch
18:03 wendall911 joined #salt
18:04 Paul_ oh, really, good point, will try now
18:06 iggy dendazen: you can't set pillars directly in the top file, you only target pillar sls files in the top file
18:06 Paul_ yeh!! iggy, you nailed it... seems working
18:06 I3olle joined #salt
18:06 dendazen oh, so i should move that set to separate sls file under pillar and include it in pillar top.sls?
18:07 iggy dendazen: it's a bit annoying when you're trying to do things like that, but it has to do with the top file being processed in a special way
18:07 iggy dendazen: correct
18:07 dendazen Thank you, i will fix that.
18:07 dendazen and try to run on minion and see if pillar shows up in pillar.items.
18:07 iggy Paul_: the sentence above that is trying to say the same thing I did, but it seems to be unclear (as you're not the first person to come in here making that same mistake)
18:09 Paul_ thx for pointing it out. I did not know that,
18:10 dendazen adn if i named that pillar sls as host.sls should my pillar top.sls look something like this? http://pastebin.com/egf5A1yd
18:12 lothiraldan joined #salt
18:17 dendazen hmm, doesn’t seem that pillar gets into minion.
18:17 dendazen salt-call pillar.items apphost
18:17 dendazen local:
18:17 dendazen ----------
18:17 spiette joined #salt
18:22 adelcast1 left #salt
18:22 I3olle joined #salt
18:23 druonysus joined #salt
18:23 druonysus joined #salt
18:25 TheOtherDude joined #salt
18:25 keimlink joined #salt
18:26 toanju joined #salt
18:28 rojem joined #salt
18:29 solidsnack joined #salt
18:29 adelcast joined #salt
18:29 iggy dendazen: paste more context... your top file went from a massive compound match to '*' and it's hard to tell what's where
18:30 dendazen ok, here.
18:30 blacked joined #salt
18:31 dendazen http://pastebin.com/XJSC30fY
18:32 dendazen in state top.sls should i include pillar folder?
18:32 tzero joined #salt
18:35 iggy no
18:36 iggy umm... you grossly misunderstood what I said earlier
18:36 iggy I didn't mean put the whole top.sls into hosts.sls
18:36 I3olle joined #salt
18:38 ALLmight_ joined #salt
18:39 ALLmight_ joined #salt
18:39 iggy http://pastebin.com/shenbA71
18:40 dendazen oh.
18:40 dendazen i see now.
18:41 dendazen also i aded pillar in my state top.sls
18:41 dendazen like this http://pastebin.com/gzu6LUPf
18:41 dendazen but i get compile error
18:41 iggy no
18:41 baweaver joined #salt
18:41 dendazen No matching sls found for 'pillar' in env 'base'
18:41 iggy states and pillars are totally separate
18:43 dendazen oh ok, i saw in docs that in top.sls i should point to pillar folder location pillar_roots: base: - pillar
18:43 dendazen is that correct?
18:44 iggy I don't know what it would be for whatever you're doing... osx salt master? masterless?
18:45 dendazen no, we have gitfs
18:45 iggy and you generally wouldn't have your pillars underneath your salt states directories... then anybody can access that data
18:45 fusionx86 joined #salt
18:46 dendazen it is not underneath, my flder structure is like this: http://pastebin.com/A42kYJ9r
18:47 dendazen i just edit the files on mac.
18:48 c10 joined #salt
18:49 dendazen Nevertheless, thanks for great help.
18:49 dendazen it’s invaluable.
18:54 racooper joined #salt
18:56 I3olle joined #salt
18:57 arif-ali joined #salt
18:58 sdm24 joined #salt
18:58 blacked joined #salt
18:59 subsignal joined #salt
18:59 badon joined #salt
19:01 sdm24 So I have a strange issue. I have a schedule pillar set to run the highstate every 30 minutes, with a 15 second splay. This schedule is called in the pillar top.sls. Before, when I did "salt '*' pillar.get schedule", it would display a "seconds: #" for each minion, with # being a number between 1-15. I ran "salt '*' saltutil.refresh_pillar", and now grains.get doesn't display that seconds value
19:02 sdm24 oh weird now its back. I guess I just needed to wait for a highstate to run on the schedule (I didn't change anything else)
19:03 sdm24 Its only back for some of the minions though. Do I just need to be patient and wait for the highstate to schedule for each minion?
19:04 dendazen there is a saying “This example configuration declares that the base environment will be located in the /srv/pillar directory. It must not be in a subdirectory of the state tree.”
19:04 hybridpollo joined #salt
19:04 dendazen in docs, what if i am using gitfs, should i create separate branch for pillar directory?
19:04 SheetiS joined #salt
19:05 Guest70 joined #salt
19:07 jcockhren dendazen: I'd suggest a separater repo for pillars
19:07 jcockhren separate*
19:08 dendazen and  define ti in master file as ext_pillar?
19:08 jcockhren yeah
19:08 dendazen when i modify master config file should i restart salt?
19:08 jcockhren yes
19:08 dendazen Thanks.
19:09 cedwards basepi: ping re: unit tests
19:12 basepi cedwards: pong
19:13 cedwards basepi: I submitted a patch yesterday (https://github.com/saltstack/salt/pull/23072), but I guess I need to update the unit tests
19:13 cedwards basepi: ...I don't know where to find those :)
19:14 bmac2 joined #salt
19:17 racooper joined #salt
19:17 OnTheRock joined #salt
19:18 ALLmightySPIFF joined #salt
19:23 * iggy guesses tests/
19:25 * cedwards admits he really hasn't looked very hard
19:25 jrluis joined #salt
19:25 druonysuse joined #salt
19:27 baweaver joined #salt
19:28 otter768 joined #salt
19:30 murrdoc joined #salt
19:32 gadams joined #salt
19:32 ktosiek joined #salt
19:34 sdm24 hmm, so I have been monitoring the splay seconds with "salt '*' pillar.get schedule:higstate:seconds, and I just had a minion that had a splay seconds result but now its off the list. Is there a different way to see what splay time it was given to run the schedule?
19:35 basepi yep, tests/unit/ =)
19:35 basepi (Sorry, got distracted
19:35 basepi )
19:36 o5k_ joined #salt
19:38 bhosmer__ joined #salt
19:42 spiette joined #salt
19:44 solidsnack joined #salt
19:49 hemphill joined #salt
19:54 bhosmer joined #salt
19:54 linjan joined #salt
19:55 baweaver joined #salt
19:58 ALLmightySPIFF joined #salt
19:59 ALLmightySPIFF joined #salt
20:02 keimlink joined #salt
20:05 tmclaugh[work] joined #salt
20:06 sdm24 joined #salt
20:16 baweaver joined #salt
20:21 hemphill I seem to be able to get salt-cloud to spin up a windows instance, but the bootstrapping part consistently fails with "ERROR: Failed to open connection - NT_STATUS_LOGON_FAILURE" anyone know what that usually means for salt-cloud?
20:22 iggy I've never even heard of anyone using salt-cloud with Windows minions
20:22 txomon|home joined #salt
20:22 hemphill lol
20:23 pdayton joined #salt
20:27 UtahDave hemphill: Usually, that means your firewall isn't open or the user creds are bad
20:30 hemphill The cert is the same one I've been using for linux hosts with no problem just with the win_username: Administrator and win_password: auto  added, so I'll check the security groups again
20:34 hemphill It's got all tcp, udp, and icmp open so I guess it has to be creds.
20:34 paul_ joined #salt
20:39 perfectsine joined #salt
20:39 ghostisic joined #salt
20:40 ghostisic Is Salt-Stack able to execute arbitrary code via minions? Ex: I have a PS script or a VB script that I want to push from the Salt-Master to it's minions and execute the PS or VB script on the host (minion).
20:40 meylor joined #salt
20:40 meylor left #salt
20:40 rhodgin joined #salt
20:43 iggy ghostisic: yes
20:43 paul_ Hi, there, I can't make salt-ssh work. The same state files work if I use command " salt '*' state.highstate", but not for " salt-ssh '*' state.hight", here are the state files and error message, can anyone take a look? http://pastebin.com/3tQ4R0qC
20:44 paul_ btw, "salt-ssh '*' test.ping" works
20:45 vimalloc joined #salt
20:46 vimalloc Is it possible to allow cmd.run via publish.runner, but then limit what commands can be run via the cmd.run?
20:46 vimalloc ie, only allow 'ls -lah /tmp/' instead of 'rm -rf /'
20:47 Ahlee wrap ls -lah into a _state instead of allowing cmd.run, allow your state
20:47 Ahlee I don't believe (but could be wrong, as usual) that arguments to states aren't parsed at that level
20:48 vimalloc ^^derp. That sounds absoultely like the right decision. Thanks!
20:51 txomon|home is it me, or at the end, in a really well done system, you just change configuration through pillars?
20:51 paul_ iggy: mind take a look my problem?
20:51 ghostisic Is Salt-Stack able to execute arbitrary code via minions? Ex: I have a PS script or a VB script that I want to push from the Salt-Master to it's minions and execute the PS or VB script on the host (minion).
20:52 solidsnack joined #salt
20:53 txomon|home ghostisic, yes, it's covered in the tutorials
20:53 iggy paul_: I don't use salt-ssh, but salt:// paths usually refer to the master... in salt-ssh you don't really have a master
20:53 SheetiS ghostisic: the cmd.script state would do what you want (run a shell script) on a *nix machine.  I've not tried it on powershell, but I can link the doc section for review.
20:54 paul_ iggy: thx, will go back to take a look at the doc
20:54 SheetiS sometimes stuff in a script might better be defined via states, but I will leave that to you to decide on what is best for you.
20:54 iggy txomon|home: you can... or you can go the opposite way and only have the bare minimum data in pillars... it's kind of personal preference
20:55 SheetiS http://docs.saltstack.com/en/latest/ref/states/all/salt.states.cmd.html#salt.states.cmd.script
21:00 cberndt joined #salt
21:01 cberndt joined #salt
21:01 murrdoc states over scripts
21:01 murrdoc for readability and logging!
21:05 nafg joined #salt
21:08 hasues joined #salt
21:12 AlexStraunoff joined #salt
21:12 thayne joined #salt
21:14 spiette joined #salt
21:16 programmerq joined #salt
21:16 roder joined #salt
21:17 I3olle joined #salt
21:19 amcorreia joined #salt
21:19 seev joined #salt
21:20 giantlock joined #salt
21:23 solidsnack joined #salt
21:25 roder Hello salt world. I have an ssh private keys (my github deploy key) in the Pillar.  I was hoping to/planning on checking the pillar sls files into my github repo. It seems counter intuitive to  check my private key in as well, but wanted to hear what ya'll thought was the best way to go. Thoughts?
21:25 seev don't put sensitive pillar files in any git repo
21:25 seev unless it's a private repo
21:26 roder ok. Thanks for the sanity check.
21:26 seev I keep them out of github entirely, for my setup, all private keys, API keys, SSL cert private keys, etc, go straight into pillar and those files are simply backed up
21:26 iggy most people are probably going to require a private repo for their pillars
21:27 roder @iggy by private, you mean - not hosted by github, I presume?
21:27 dingo if you must share the pillar to the pubic, maybe a very dirty solution, since its just yaml, you could have a pre-processor that inserts the ssh keys/etc from an off-repository/local/trusted location
21:27 iggy GitHub has the concept of private repos
21:28 seev I don't trust stupid Github with my security
21:28 iggy you are always trusting someone
21:28 roder FWIW, this is in a private github repo.
21:28 racooper our university has its own github installation onsite, not connected with github.com. works great.
21:28 dingo i gave someone collaborator access to a repo once -- he immediately forked and made it public, that was a lesson
21:28 iggy then you should be fine
21:29 otter768 joined #salt
21:29 seev it's not a bad idea to use Stash or just bare Git + SSH for private repos anyhow
21:29 * roder facepalms @dingo
21:29 seev it's a good skillset to have, if you can administer a Git repo without any fancy UIs
21:29 iggy weird, they don't allow you to make public repos private, you'd think they would work similarly the other way
21:31 kaos01 joined #salt
21:35 gwmngilfen joined #salt
21:36 eyeoh_ bitbucket lets you use private repos for free
21:39 o5k joined #salt
21:39 Dev0n joined #salt
21:39 bhosmer_ joined #salt
21:43 speedlight joined #salt
21:43 speedlight joined #salt
21:44 jcockhren eyeoh_++
21:44 jcockhren then there's gitlabHQ
21:44 doug joined #salt
21:45 doug i'd like to restart pm2 unless it was started this run, how can i express that?
21:47 meylor joined #salt
21:48 doug like, run one state or another but not both.
21:50 radd joined #salt
21:51 theologian joined #salt
21:54 doug maybe an inverse watch?
21:55 VR-Jack2 to my knowledge, there isn't a good unless state. You can run unless with a command that checks start time, perhaps
21:55 murrdoc u want it restarted only once ?
21:56 doug murrdoc: i'd like it restarted if it wasn't just installed
21:56 doug murrdoc: another state makes sure it's installed, and will start it up if it wasn't.
21:56 tmclaugh[work] joined #salt
21:56 murrdoc is this because of config files ?
21:57 doug it's because some machines won't have it installed yet
21:57 murrdoc ah
21:57 doug and other machines will have it installed but the code has changed
21:57 murrdoc u need it installed across a few servers
21:57 murrdoc and restarted only if a config / code file changes
21:57 murrdoc but not otherwise
21:58 iggy seems like you should be able to represent that with the standard requisites
21:58 iggy unless I'm missing something
21:59 baweaver joined #salt
22:01 murrdoc if the pkg install starts the service do pkg.installed: - onchanges: stop-service
22:01 murrdoc and then let the watched files start the service using listen_in
22:06 ajw0100 joined #salt
22:08 kermit joined #salt
22:11 stbenjam joined #salt
22:17 dingo if you want a state to reboot, use order: last along with something like a cmd.run: "at +1m reboot"
22:18 murrdoc or use event.ping, tell reactor to reboot the minion
22:19 iggy ewww, order: last
22:38 solidsnack joined #salt
22:47 hasues left #salt
22:48 meylor joined #salt
22:49 ek6 iggy: only time i use order is like that...its not THAT bad
22:51 yomilk joined #salt
22:53 ajw0100 joined #salt
22:53 iggy I just let the minion reboot when it's ready
22:53 iggy it always seems to do the right thing
22:55 ek6 not sure i would do it for reboot...but I certainly have my share of order: last   for me it seems to go along when i have to handle a bunch of on_fail
22:56 StDiluted joined #salt
22:56 iggy of course I don't mean reboot... I'm talking about reloading... we don't reboot, we just respawn
22:57 iggy so yeah, I'm confusing people (including myself)
22:57 * iggy wanders off back to the corner
22:57 ek6 happens to me all the time...i just strive to confuse myself last
22:58 murrdoc order:last
22:59 iggy touche
22:59 baweaver joined #salt
22:59 echo joined #salt
23:00 murrdoc " ek6:  BOOO...because that wasnt even public ridicule worthy "
23:00 murrdoc uh its all public ridicule worthy
23:00 tmclaugh[work] joined #salt
23:03 Matthews_ joined #salt
23:04 Ymage joined #salt
23:05 ajw0100 joined #salt
23:05 kermit joined #salt
23:06 blacked1 joined #salt
23:10 bfoxwell joined #salt
23:11 mosen joined #salt
23:11 patrek joined #salt
23:14 rojem joined #salt
23:15 rideh joined #salt
23:18 JDiPierro joined #salt
23:20 giantlock joined #salt
23:21 Nazca joined #salt
23:25 vstoniest joined #salt
23:26 gwmngilfen joined #salt
23:26 subsignal joined #salt
23:27 CeBe joined #salt
23:30 otter768 joined #salt
23:35 baweaver joined #salt
23:38 ajw0100 joined #salt
23:39 jonatas_oliveira joined #salt
23:40 khaije|io joined #salt
23:40 dharper_ii joined #salt
23:40 vstoniest joined #salt
23:40 bhosmer_ joined #salt
23:45 bluenemo_ joined #salt
23:53 JDiPierro joined #salt
23:55 wt can anyone here with 2014.7.5 and a gitfs backend please run "salt-call cp.list_master" from a minion and tell me if the files in the list are prefixed with "../"?
23:56 wt and tell me if you salt-master has the "-d" arg
23:57 StDiluted joined #salt
23:59 rhodgin joined #salt

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