Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2017-08-25

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

All times shown according to UTC.

Time Nick Message
00:07 cyborg-one joined #salt
00:14 sp0097 left #salt
00:19 omie888777 joined #salt
00:20 GMAzrael joined #salt
00:26 cgiroua joined #salt
00:27 masber joined #salt
00:33 tsia joined #salt
01:06 swills joined #salt
01:06 swills joined #salt
01:34 omie888777 joined #salt
01:41 soumit joined #salt
01:50 swills joined #salt
01:51 ilbot3 joined #salt
01:51 Topic for #salt is now Welcome to #salt! <+> Latest Versions: 2016.11.7, 2017.7.1 <+> Support: https://www.saltstack.com/support/ <+> Logs: http://irclog.perlgeek.de/salt/ <+> Paste: https://gist.github.com/ <+> See also: #salt-devel, #salt-offtopic <+> We are volunteers and may not have immediate answers
02:00 twiedenbein joined #salt
02:04 debian112 joined #salt
02:05 hammer065 joined #salt
02:06 omie888777 joined #salt
02:09 swills joined #salt
02:09 swills joined #salt
02:20 jab416171 joined #salt
02:23 kuromagi^ joined #salt
02:27 frygor_ joined #salt
02:29 skrobul joined #salt
02:30 rideh joined #salt
02:50 k_sze joined #salt
02:59 Church- joined #salt
03:16 onlyanegg joined #salt
03:20 pipps joined #salt
03:24 dxiri joined #salt
03:26 Church- joined #salt
03:36 michelangelo joined #salt
03:56 onlyanegg joined #salt
03:56 sh123124213 joined #salt
03:59 zerocoolback joined #salt
04:01 onlyaneg1 joined #salt
04:10 obimod joined #salt
04:14 aleph- joined #salt
04:25 Church- joined #salt
04:27 aleph- joined #salt
04:37 onlyanegg joined #salt
04:43 AnotherNick joined #salt
05:04 Church- joined #salt
05:14 onlyanegg joined #salt
05:15 hoonetorg joined #salt
05:23 Bock joined #salt
05:36 felskrone joined #salt
05:39 _KaszpiR_ joined #salt
05:39 sh123124213 joined #salt
05:43 impi joined #salt
06:16 tom[] joined #salt
06:19 preludedrew joined #salt
06:20 evle joined #salt
06:22 onlyanegg joined #salt
06:35 NegiLXXXVIII joined #salt
06:43 NegiLXXXVIII hi. I found something strange with the file state on a widows minon version 2017.7.1. The state module seem to be a different version than one in the current 2017.7.1 branch. If I try to just copy the state module to the custom modules folder on the master an try to run a state I get the error that the platform utils is missing.
06:44 NegiLXXXVIII Did anyone else notice this or this the intendet behavior?
06:46 iggy did you do a saltutil.sync_all ?
06:47 NegiLXXXVIII i run a state.apply
06:47 NegiLXXXVIII to rnu a highstate
06:47 NegiLXXXVIII *run
06:53 NegiLXXXVIII the state is also different in previous minion versions like 2016.11
07:04 jhauser joined #salt
07:10 johnj joined #salt
07:11 darioleidi joined #salt
07:17 NegiLXXXVIII @iggy: is there a fault on my side or should i open a issue in git for this?
07:17 jessexoc joined #salt
07:18 iggy well, there shouldn't be a 2017.7.1 branch for one
07:18 iggy so if there is, yes, report that
07:18 iggy if the 2017.1 branch is ahead of the latest release, that's not out of the ordinary
07:19 NegiLXXXVIII ok thanks
07:19 iggy and I don't think highstate does a sync_all (it does refresh_pillar)
07:19 iggy but I could be wrong
07:20 iggy I know our provisioning process does a standalone sync_all ahead of the highstate for a reason
07:26 GMAzrael joined #salt
07:37 zulutango joined #salt
07:38 NegiLXXXVIII well so far the highstate always did a sync_all and synchronized the custom states and modules.
07:41 NegiLXXXVIII the problem also is not that the highstate doesn't provide the modules. it is that a utils module in the lib folder of salt is missing and that the windows minion seem to be on a different level than the brach it was made from.
07:42 NegiLXXXVIII anyway. i'm opening a ticket and i'll see what'll happen
07:46 jas02 joined #salt
07:51 jas02 joined #salt
07:55 jas02 joined #salt
08:04 impi joined #salt
08:04 gmoro_ joined #salt
08:08 _KaszpiR_ joined #salt
08:11 johnj joined #salt
08:13 mikecmpbll joined #salt
08:26 _KaszpiR_ joined #salt
08:27 GMAzrael joined #salt
08:44 mquin joined #salt
08:59 o1e9 joined #salt
09:08 aldevar joined #salt
09:10 johnj joined #salt
09:15 xet7 joined #salt
09:20 kedare joined #salt
09:21 kedare Hi all, small question, how can I run a command from a state and use the result of the command in another state ? Typically I want to run the “svnversion” command and save the result in a grain, but I can’t use cmd.run from jinja as this needs to be run after a specific state
09:26 peters-tx joined #salt
09:32 coredumb kedare: you can call the cmd module from the other state
09:32 babilen kedare: I'd still implement a custom grain and update that after you executed whatever state you have to execute for that to work
09:32 babilen Just handle the "undefined" situation gracefully
09:33 babilen You are, in particular, looking for the "reload_grains: True" argument to that state
09:34 babilen Require the state that "makes the grain tick" in states that, well, require the grain to be set
09:37 kedare So I would need to run it from another state.apply ?
09:37 babilen Run what?
09:37 kedare The command
09:37 kedare if it’s the easiest solution it’s fine for me
09:37 babilen My understanding was that you run it in a custom grain
09:38 kedare I an filling a custom grain with the result of the command yes
09:38 kedare It’s not used anywhere else for now, it’s just to have it easily accessible if needed (for now)
09:38 babilen There you go then
09:38 babilen What more do you need?
09:38 kedare I was just thinking if there was a way to run it in the same state so I don’t need to do more changes :)
09:39 kedare I tough I saw that somewhere but maybe I’ve dream
09:39 kedare Like running a state, saving the result in a named variable and reusing it somewhere else
09:40 babilen What you are thinking of is independent of states, but simply a salt execution function call that is being saved in a jinja variable I guess
09:40 babilen To me a custom grain feels right
09:41 kedare That’s an option too, but here the problem was that the jinja function would be called before I would have the correct SVN state, so it would not work in my case (Because basically I want to save what if the SVN version that has been fetched on the state that just ran)
09:41 kedare what is*
09:41 kedare So if I use that I would  have the SVN version from before
09:41 kedare As the function would be run before the state is applied and the version updated
09:41 babilen Indeed
09:41 babilen Which was, as I understand it, the issue you wanted to address
09:42 kedare Yes
09:42 kedare I’ll just run it from another state running after so
09:42 kedare I think it’s the easiest solution :)
09:42 babilen How is that easier than updating your already existing custom grain?
09:43 babilen I obviously haven't seen your code, so if you think another approach is easier then just go with that :)
09:43 kedare That will update the custom grains
09:44 kedare But it needs to be run after the state
09:44 babilen What does?
09:44 kedare The "svnversion"
09:44 babilen Could you paste some examples, I feel that it is much easier to talk about it that way
09:45 babilen You have your custom grain, it's value might reflect an earlier state (either undefined, or outdated). This state might change over time (as you run states) and you would simply trigger a grain update (by setting "- reload_grains: True" in all states that result in a changed value)
09:45 babilen The downside of this is that this will reload all grains
09:46 kedare Currently I deploy new versions like that : https://gist.github.com/kedare/bcc2a8a338f2745f67be95d3152c10e9
09:46 kedare (Just a part of the states)
09:47 kedare What I want to do is that after the package have been deployed, burn into ci:current:revision:{{package}} the deployed revision (That can be obtained by running “svnversion” from the directory)
09:48 babilen That's the svn.latest state?
09:48 kedare Yes
09:49 babilen Set "- reload_grains: True" in that state and your grain will be updated
09:49 babilen That approach achieves what you want, but doesn't really scale well to hundreds of custom grains and/or repositories
09:49 kedare But the svn.latest doesn’t write any grains
09:50 kedare That’s why  I tough running another state.apply after, on another .sls file that would run some grains.present with a value from salt[“cmd.run”](“svnversion”)
09:50 babilen It results in a change of the grains value though, doesn't it?
09:51 kedare svn.latest doesn’t change anything in the grains
09:51 babilen I thought it results in a svn version change that would be reflected in your custom graim
09:51 babilen *grain
09:52 kedare No, I need to update them with another state, that’s the thing
09:52 bowhunter joined #salt
09:52 kedare It does update the svn version of the package, but then I need to write it on the grain
09:52 babilen Sorry, are we talking about the same "custom grain" ? I am referring to https://docs.saltstack.com/en/latest/topics/grains/#writing-grains
09:53 kedare Hmm no, I didn’t know you could do that hehe
09:53 babilen Right, I understand why you are confused now :)
09:53 kedare I was thiking about running this from another state: https://docs.saltstack.com/en/latest/ref/states/all/salt.states.grains.html#salt.states.grains.present
09:54 kedare But if there’s a better way to code it
09:54 babilen I had though that you had already written Python code that (traverses/walks) a certain directory with your repositories and generates a dictonary of SVN versions
09:54 kedare No :)
09:54 babilen *thought
09:54 kedare Not yet at least hehe
09:55 kedare But that would probably be a good option
09:56 babilen If you had that code, updating that would be as easy as setting "- reload_grains: True" in a state that results in a change or running saltutil.refresh_grains once if you have many such states
09:56 kedare I’ll check this path :)
09:57 kedare Just to make sure : I can access pillars when writing custom grains ?
09:57 kedare Because that’s needed in my case
09:57 babilen No, you can't
09:57 kedare Oh ok
09:57 babilen Grains are before pillars
09:57 kedare So that will be complicated haha
09:57 kedare As all the repositories config is in pillars
09:58 kedare I will write a .sls just for that so :)
09:58 babilen As you don't know {{ pillar['ci']['svn']['environment'] }}
09:58 kedare Also yes
09:58 kedare The package name, the environments, there’s a lot defined in the pillars about that
09:58 babilen You could use pillarstack and write a pillar and refresh that I guess
09:59 babilen A thousand ways to do things
09:59 babilen I started from the "I have a custom grain already, how do I update that?" misunderstanding :(
09:59 kedare Hehe no problem :)
09:59 kedare Thank you for your time :)
09:59 babilen All the best!
10:05 JohnnyRun joined #salt
10:12 johnj joined #salt
10:16 aleph- joined #salt
10:17 aleph- joined #salt
10:20 Church- joined #salt
10:22 Church- joined #salt
10:29 debian112 joined #salt
10:31 jeddi joined #salt
10:31 debian1121 joined #salt
10:37 tacoboy joined #salt
10:55 aldevar joined #salt
11:09 high_fiver joined #salt
11:13 johnj joined #salt
11:15 jas02 joined #salt
11:17 jas02 joined #salt
11:33 pualj_ joined #salt
11:37 _KaszpiR_ joined #salt
11:42 schasi left #salt
11:42 schasi joined #salt
11:51 Hybrid joined #salt
11:58 yuhl joined #salt
11:58 flight884 joined #salt
11:59 yuhl joined #salt
12:07 johnj joined #salt
12:07 ssplatt joined #salt
12:09 Hybrid joined #salt
12:13 Tyrant_ joined #salt
12:16 evle joined #salt
12:17 flight884 joined #salt
12:18 Nahual joined #salt
12:19 johnkeates joined #salt
12:24 sp0097 joined #salt
12:33 saltsa joined #salt
12:33 wedgie joined #salt
12:33 descrepes joined #salt
12:33 Sacro joined #salt
12:33 jeblair joined #salt
12:33 preludedrew joined #salt
12:33 lorengordon joined #salt
12:33 cliluw joined #salt
12:33 Bock joined #salt
12:33 beebeeep joined #salt
12:33 matti joined #salt
12:33 matti joined #salt
12:33 systemexit joined #salt
12:33 honestly joined #salt
12:33 peters-tx joined #salt
12:33 gareth__ joined #salt
12:34 Udkkna joined #salt
12:34 jas02 joined #salt
12:36 scc joined #salt
12:37 nledez joined #salt
12:37 nledez joined #salt
12:38 carmony joined #salt
12:39 flebel joined #salt
12:42 flight884 joined #salt
12:48 flight884 joined #salt
12:54 Swant joined #salt
12:54 GMAzrael joined #salt
12:54 Naresh joined #salt
12:55 gh34 joined #salt
12:59 XenophonF joined #salt
13:03 jeremytiki joined #salt
13:03 ssplatt joined #salt
13:07 jeremytiki Hi all. I'm having some issues with SaltMine match grains. If I run mine.get to match by names and blobs, it returns the correct information, however if I try matching to grains, mine.get returns nothing. I made sure that the grains are functioning and registering properly by matching through the command line and running test.ping and I made sure that the mine functions are setup properly by matching against a blob name. Any idea's what th
13:07 jeremytiki e problem might be?
13:07 jeremytiki Here is some example output: https://gist.github.com/anonymous/e8b73eccfab67f5707eb574f07627564
13:31 gmoro joined #salt
13:43 zerrac joined #salt
13:45 zerrac left #salt
13:45 zerrac joined #salt
13:48 pualj_ joined #salt
13:49 zerrac Hello there, i have trouble connection to a local ldap to create users. I tried with https://gist.github.com/anonymous/e522e06dd9f913e2ebe5b3e4a3e8ca87 .
13:49 zerrac salt 'host' state.highstate finish with : "          ID: ldap_add_entries
13:49 zerrac Function: ldap.managed
13:49 zerrac Result: False
13:49 zerrac Comment: An exception occurred in this state: Traceback (most recent call last):
13:49 zerrac File "/usr/lib/python2.7/dist-packages/salt/state.py", line 1837, in call
13:49 zerrac **cdata['kwargs'])
13:49 zerrac File "/usr/lib/python2.7/dist-packages/salt/loader.py", line 1794, in wrapper
13:50 zerrac return f(*args, **kwargs)
13:50 zerrac File "/usr/lib/python2.7/dist-packages/salt/states/ldap.py", line 250, in managed
13:50 zerrac connect = __salt__['ldap3.connect']
13:50 zerrac File "/usr/lib/python2.7/dist-packages/salt/loader.py", line 1113, in __getitem__
13:50 zerrac func = super(LazyLoader, self).__getitem__(item)
13:50 zerrac File "/usr/lib/python2.7/dist-packages/salt/utils/lazy.py", line 98, in __getitem__
13:50 zerrac return self._dict[key]
13:50 coredumb zerrac: why not use a pastebin ?
13:50 zerrac Sorry : https://gist.github.com/anonymous/ba7e9942b425c2d88eab1bdefe9fc072
13:53 impi joined #salt
13:56 MajObviousman I've got a funny question about relative includes
13:57 MajObviousman if I have a dirwithstates/init.sls I can invoke it as 'state.sls dirwithstates'. But would relative includes be in dirwithstates/ or its parent directory?
13:57 MajObviousman and does invoking it directly as dirwithstates/init.sls change that?
13:58 edrocks joined #salt
14:00 racooper joined #salt
14:01 MajObviousman testing seems to indicate it's not clever enough to discern the difference
14:01 DammitJim joined #salt
14:05 MajObviousman https://gist.github.com/anonymous/58d94201630530404ea11ae2f7144a28
14:06 christopherl-sf joined #salt
14:08 MajObviousman yep, doesn't discern
14:08 cgiroua joined #salt
14:09 babilen MajObviousman: It follows Python packages in that regard
14:10 christopherl-sf_ joined #salt
14:11 MajObviousman sounds like if I want to do jinja templating, then I shouldn't use init.sls
14:11 onlyanegg joined #salt
14:11 MajObviousman err block templating
14:13 ivanjaros joined #salt
14:19 edrocks joined #salt
14:20 kedare_ joined #salt
14:22 kedare joined #salt
14:26 LostSoul joined #salt
14:27 GMAzrael joined #salt
14:34 jbailey joined #salt
14:34 zerrac left #salt
14:36 eseyman joined #salt
14:39 jbailey_ joined #salt
14:40 dxiri joined #salt
14:44 concerti joined #salt
14:48 zer0def joined #salt
14:49 pdayton joined #salt
14:50 tacoboy joined #salt
14:52 lkolstad joined #salt
14:59 cgiroua_ joined #salt
14:59 debian112 joined #salt
15:00 jeremytiki joined #salt
15:04 omie888777 joined #salt
15:14 LostSoul joined #salt
15:19 nbuchanan joined #salt
15:22 pdayton joined #salt
15:23 nbuchanan joined #salt
15:25 nbuchanan joined #salt
15:27 nbuchanan I just updated to 2017.7 and token auth isn't working "Failed to authenticate!" msgs. Any ideas? we use ldap ext auth and I've check the file permissions in /var/cache/salt/...
15:27 Cottser joined #salt
15:32 fritz09 joined #salt
15:36 mquin left #salt
15:36 dxiri joined #salt
15:36 cgiroua joined #salt
15:37 Brew joined #salt
15:44 cgiroua_ joined #salt
15:48 tiwula joined #salt
15:55 tiwula joined #salt
16:11 Felgar joined #salt
16:17 onlyanegg joined #salt
16:21 PotatOS joined #salt
16:24 openfly joined #salt
16:24 openfly hey salt people.  is there a good way to query for a list of nodes by pillar/grain value set present?
16:25 openfly i suppose i could do a salt '*' pillars.items and just manually search and build my own list
16:25 openfly but is there a better way?
16:26 whytewolf you mean something like salt -G 'set:grain:value' test.ping
16:26 openfly sorta
16:26 openfly but i am doing this in python to get a list of minion ids
16:27 openfly so yes but... export the list before doing the ping operation
16:28 whytewolf yeah, since the minions responding are what builds the list. that part won't be possable
16:28 openfly pity
16:29 openfly one would think with pillars it would be
16:29 openfly since they are set on the salt master side
16:30 whytewolf everyone things that but the master doesn't keep that data avalible directly. it only renders the pillars when a minion calls for the data.
16:30 whytewolf s/things/thinks
16:30 openfly i am continually disappointed by the architecture of salt.
16:30 whytewolf then fix it
16:31 openfly would if i had the time.
16:31 openfly actually i'd just do a complete rewrite.
16:31 openfly but... no one is paying for that =P
16:35 vexati0n joined #salt
16:35 impi joined #salt
16:37 shanth__ joined #salt
16:40 vexati0n salt is fine
16:41 vexati0n i wrote a sql frame around it to keep track of things that it would just drop otherwise
16:41 vexati0n remember it's a piece of your infrastructure, not the whole thing.
16:42 GMAzrael joined #salt
16:46 fatal_exception joined #salt
16:50 edrocks joined #salt
16:54 pipps joined #salt
16:55 pipps joined #salt
16:59 GMAzrael joined #salt
17:01 jeremytiki joined #salt
17:04 shanth_ joined #salt
17:09 junkin joined #salt
17:18 aleph- joined #salt
17:19 cyborg-one joined #salt
17:23 nixjdm joined #salt
17:24 pipps joined #salt
17:25 jucv joined #salt
17:25 dxiri joined #salt
17:27 shanth_ does anyone know what service.running is expecting from the service to mark starting it as successful? on freebsd im having issues getting it to mark apache-solr as successfully started. it indeed starts the process. i've tried adding init_delay 30 seconds and it still shows as failed the first time
17:27 shanth_ a second run says that the service is running
17:28 Church- joined #salt
17:28 whytewolf on bsd I am not sure. but i know in older centos that was service based instead of systemd, it makes sure that the command that runs returns an exit code of 0
17:29 shanth_ hmm
17:30 shanth_ i wonder if because the service command runs su -m user -c command that it doesn't get a return code? wild shots in the dark here
17:33 fran_ joined #salt
17:34 pipps joined #salt
17:34 ivanjaros joined #salt
17:37 LostSoul joined #salt
17:39 eseyman joined #salt
17:42 aleph- joined #salt
17:49 DammitJim joined #salt
17:50 jim1591 joined #salt
17:55 jeremytiki joined #salt
18:12 pipps joined #salt
18:14 DammitJim joined #salt
18:15 DammitJim joined #salt
18:23 schasi shanth_: I have a similar problem; that service.running on FreeBSD reports wrong for apache sometimes
18:24 schasi https://github.com/saltstack/salt/blob/develop/salt/modules/freebsdservice.py
18:25 schasi cmd = '{0} {1} onestatus'.format(_cmd(jail), service) results[service] = not __salt__['cmd.retcode'](cmd,
18:26 obimod joined #salt
18:28 Church- joined #salt
18:28 dxiri joined #salt
18:29 pipps joined #salt
18:36 onlyanegg Is anyone familiar with the hadoop formula? I'm wondering why hadoop users get created with ssh keys. Does HDFS replicate blocks over scp or something?
18:38 edrocks joined #salt
18:38 edrocks joined #salt
18:38 whytewolf no, but hadoop manegment does need ssh access for control commands. iirc
18:40 nixjdm joined #salt
18:41 whytewolf https://stackoverflow.com/questions/13909603/why-do-we-need-hadoop-passwordless-ssh
18:41 onlyanegg ah, thank you for that!
18:49 Guest73 joined #salt
18:57 christopherl-sf joined #salt
19:01 _KaszpiR_ joined #salt
19:03 openfly vexati0n i mean... it's kinda why i see salt as a cluster ssh solution rather than a CFM
19:03 openfly it's not really big on persistence layers.
19:04 A_Person__ joined #salt
19:04 openfly or proper scheduling
19:06 jeremytiki left #salt
19:09 A_Person__ joined #salt
19:13 A_Person__ so I am trying to use multiple environments with git states and git external pillars, a couple of my pillar files use salt.saltutil.runner('pillar.show_pillar') to extract data from another external pillar (in this case, a pillar created to contain the output of "terraform output -json").. this worked before I introduced multiple environments, but now it seems at the time of show_pillar the terraform output hasn't been loaded
19:14 A_Person__ is there a better way to do this or make it work? :P
19:15 A_Person__ show_top for the various environments seems to report the correct top file for nodes, and pillar.items contains the expected stuff, but state.show_highstate errors
19:16 openfly i'd reverify your top structure
19:16 openfly and ensure it's importing the pillars to ALL environments
19:16 openfly and not just one.
19:19 A_Person__ I have my pillar top set differently in each branch to import pillars based on the minion ids that should be in that environment (only), and my state top is set to apply the corresponding formulas in the same environment to the same node (only)
19:19 A_Person__ so e.g. show_top saltenv=base is empty
19:21 A_Person__ should I need the pillar data in the base environment if there are no states in that environment?
19:21 openfly i don't believe so.
19:22 openfly but the way i structure is we feed from a production top.sls down and use the tier'ed top files as overrides.
19:22 openfly so dev overrides qa etc
19:22 openfly but the default is the production top.sls
19:23 openfly gotta jet... code time
19:23 openfly left #salt
19:24 Church- joined #salt
19:28 GMAzrael joined #salt
19:28 frew I'm building a stateful command; is there any guidance on what the output JSON object should look like?
19:29 frew I was just gonna do like, {"created users": ["frew", "joe"]}
19:33 ChubYann joined #salt
19:39 nixjdm joined #salt
19:43 aldevar left #salt
19:43 XenophonF joined #salt
19:52 SneakyPhil joined #salt
19:54 pipps joined #salt
19:54 schasi joined #salt
19:57 miruoy joined #salt
19:57 darioleidi joined #salt
20:01 pipps joined #salt
20:02 christopherl-sf_ joined #salt
20:04 GMAzrael joined #salt
20:08 Sarphram joined #salt
20:08 darioleidi joined #salt
20:15 Sarph joined #salt
20:20 pualj joined #salt
20:26 ahrs joined #salt
20:26 christopherl-sf joined #salt
20:27 Sarphram joined #salt
20:40 nixjdm joined #salt
21:02 pipps joined #salt
21:03 latouche joined #salt
21:17 cyborg-one joined #salt
21:22 omie888777 joined #salt
21:27 masber joined #salt
21:34 frew jj/2
21:34 frew woops
21:36 DanyC joined #salt
21:40 nixjdm joined #salt
21:46 DanyC joined #salt
21:48 GMAzrael joined #salt
21:49 it_dude joined #salt
22:00 A_Person___ joined #salt
22:03 Guest73 joined #salt
22:03 fatal_exception joined #salt
22:18 debian112 joined #salt
22:19 ssplatt joined #salt
22:20 tru_tru joined #salt
22:27 tobstone joined #salt
22:40 nixjdm joined #salt
22:52 Neighbour joined #salt
23:04 omie888777 joined #salt
23:06 omie888777 joined #salt
23:10 mikecmpbll joined #salt
23:42 bowhunter joined #salt
23:51 debian1121 joined #salt
23:55 bcat joined #salt

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