Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2018-05-10

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

All times shown according to UTC.

Time Nick Message
00:00 onslack joined #salt
00:24 zerocoolback joined #salt
00:30 itamarjp good night
00:43 jamtoast joined #salt
00:48 noobiedubie joined #salt
00:53 wongster80 joined #salt
01:00 packeteer joined #salt
01:08 wongster80 joined #salt
01:13 eseyman joined #salt
01:16 dendazen joined #salt
01:17 dxiri joined #salt
01:22 evle4 joined #salt
01:23 wongster80 joined #salt
01:56 ilbot3 joined #salt
01:56 Topic for #salt is now Welcome to #salt! <+> Latest Versions: 2017.7.5, 2018.3.0 <+> Support: https://www.saltstack.com/support/ <+> Logs: http://irclog.perlgeek.de/salt/ <+> Paste: https://gist.github.com/ <+> See also: #salt-devel, #salt-offtopic, and https://saltstackcommunity.herokuapp.com (for slack) <+> We are volunteers and may not have immediate answers
02:06 shiranaihito joined #salt
02:07 dendazen_ joined #salt
02:14 ddg joined #salt
02:30 dxiri joined #salt
02:43 dendazen joined #salt
03:16 Psi-Jack In a jinja template, how would I get the first IPv4 IP of an interface? I've been running through various options, and getting nothing, or just an IPv6 IP. WHat I have currently that I'm trying to use is:
03:16 Psi-Jack {{ grains['ip4_interfaces'][pillar.get('consul:eth_interface', 'eth0')] | first }}
03:16 Psi-Jack This results in: Jinja variable No first item, sequence was empty.
03:18 Psi-Jack salt 'hv3.*' pillar.get 'consul:eth_interface' returns the expected value of vmbr0, which I know has the IP I'm looking for.
03:24 Vye joined #salt
03:25 ddg joined #salt
03:30 Psi-Jack Well, this seems to work, but wasn't exactly what I was hoping for, since it doesn't take an interface that can be configured with a pillar: {{ grains.fqdn_ip4 | first }}
03:34 dxiri joined #salt
03:58 MTecknology what are you even trying to do?
04:05 ddg joined #salt
04:08 Psi-Jack I'm writing a state for installing and setting up consul, and I wanted to get the IP of an IP specifically, of which could come from a defined pillar to set which interface to get that IP from. For the advertise_address setting for consul.
04:10 zerocoolback joined #salt
04:13 Psi-Jack I got everything pretty much perfect, except for getting the IP the way I want. Using grains.fqdn_ipv4 | first.. But that doesn't take an interface to get the IP from. heh
04:15 MTecknology are you trying to get the ip address of the system to use in a state or are you trying to define something in pillar that uses an ip address?
04:16 Psi-Jack In a template specifically. The consul.hcl config file template, which actually generates a json configuration from pillar and grains data.
04:16 vaelen joined #salt
04:17 MTecknology that explanation didn't really do anything for clarity..
04:17 Psi-Jack I want to, within a pillar, be able to optionally define a value that defines which ethernet interface to use. Within the template, default to eth0 if not defined in the pillar.
04:18 Eugene joined #salt
04:18 Psi-Jack Otherwise, get the IPv4 IP specific to the interface defined in the pillar, or the default eth0.
04:19 DoomPatrol joined #salt
04:20 Psi-Jack Does that clarify things better?
04:22 harkx joined #salt
04:34 Eugene joined #salt
04:59 justanotheruser joined #salt
05:00 xet7 joined #salt
05:13 sauvin joined #salt
05:29 UForgotten joined #salt
05:52 briner joined #salt
06:01 stooj joined #salt
06:19 Ricardo1000 joined #salt
06:24 CrummyGummy joined #salt
06:33 DanyC joined #salt
06:35 Wuodan joined #salt
06:36 Wuodan joined #salt
06:37 Wuodan joined #salt
06:39 CrummyGummy joined #salt
06:42 sjorge joined #salt
06:44 rollniak joined #salt
06:46 tiwula joined #salt
06:56 upb joined #salt
07:02 CrummyGummy joined #salt
07:20 tom[] joined #salt
07:26 orichards joined #salt
07:40 Yoda-BZH joined #salt
07:40 Yoda-BZH joined #salt
07:41 crux-capacitor joined #salt
07:53 mikecmpbll joined #salt
08:02 inad924 joined #salt
08:12 DanyC joined #salt
08:27 DanyC joined #salt
08:29 APLU joined #salt
08:29 dmaphy joined #salt
08:29 glock69[m] joined #salt
08:29 fujexo[m] joined #salt
08:29 alj[m] joined #salt
08:29 viq[m] joined #salt
08:30 Mattch joined #salt
08:30 haam3r Psi-Jack So something like: https://gist.github.com/haam3r/f14520cb67b53e65854c70d11af88cfb
08:32 Mogget joined #salt
08:42 Cadmus Hello. I'm having a problem with a file.managed state, it pulls a URL from our build server, but then seems to not download it again even if the file changes. Clearing the cache made it download again, do I just need a file.not_cached on that URL before my file.managed?
08:53 arlyon joined #salt
09:00 APLU joined #salt
09:01 MTecknology Cadmus: if the template/file changes on the master, then the checksum for local cache would be invalidated and a new file should be pulled. Are you absolutely sure the file on the master changed?
09:06 dmaphy joined #salt
09:08 eseyman joined #salt
09:14 Cadmus MTecknology: It's not a salt URL, but an http one. Curling it did show a change, but the file.managed status did nothing with it until I cleared the cache.
09:16 Cadmus Presumably you can ask the master for the checksum if it's salt:// but you can't do that with HTML, is it time-based expiry? Anyway I guess my real quesion is does file.not_cached do what I think it does?
09:16 Cadmus http*
09:17 MTecknology isn't a checksum required for http?
09:18 Cadmus We have to skip_verify as we don't have the checksums available.
09:18 MTecknology then there ya go..
09:19 Cadmus Basically our build system won't actually write the checksum file until after its called salt, so we have to yolo it
09:20 Cadmus Right, that makes more sense. I too would prefer the checksums, but I can't redo our toolcahin right now, so is not_cached the answer here?
09:29 sjorge joined #salt
09:32 Processus42 joined #salt
09:35 ExtraCrispy joined #salt
09:43 ECDHE_RSA_AES256 joined #salt
09:45 NVX joined #salt
09:47 inad923 joined #salt
09:54 harkx what is the recommended install for ubuntun 18 ? (I don't see a specific repo yet for this release)
09:54 harkx -n
10:00 Waples_ joined #salt
10:05 jerrykan[m] joined #salt
10:05 freelock joined #salt
10:05 atmoz joined #salt
10:05 rtr63gdh[m] joined #salt
10:05 viccuad joined #salt
10:05 hoverbear joined #salt
10:05 aboe[m] joined #salt
10:05 brejoc[m] joined #salt
10:05 Tenyun[m] joined #salt
10:05 viq[m] joined #salt
10:05 toofoo[m] joined #salt
10:05 alj[m] joined #salt
10:05 gomerus[m] joined #salt
10:05 ThomasJ|m joined #salt
10:05 glock69[m] joined #salt
10:05 gomerus[m]1 joined #salt
10:05 fujexo[m] joined #salt
10:25 fernie joined #salt
10:25 toanju joined #salt
10:34 Cadmus not_cached *does* do what I want it to by invalidating just one cache file. Sadly this means it overwrites the file every time, which means it will restart the dependent service every time. Ouch
10:39 Cadmus Previously we had an extra curl step, which we might have go back to which is super-annoying
10:41 noobiedubie joined #salt
11:02 Waples_ joined #salt
11:03 babilen harkx: https://repo.saltstack.com/#ubuntu
11:03 babilen Don't think that 18 has been released yet
11:04 babilen Well, Ubuntu has released, but Salt hasn't prepared packages for that release. Packages for xenial might very well work or you grab the packages in the Ubuntu repos.
11:12 inad924 joined #salt
11:29 noobiedubie joined #salt
11:36 dendazen joined #salt
11:40 zerocoolback joined #salt
11:41 qman__ joined #salt
11:44 crux-capacitor joined #salt
11:47 orichards joined #salt
11:53 eMBee is anyone aware of a script or a tool to dist-upgrade a debian minion to the next release?
11:53 eMBee or do i update the sources and run the update command manually?
11:54 harkx ok, thanks babilen
11:56 harkx eMBee, i think you first need to update the sources and then do the dist-upgrade.. (follow debian's guide on the order of things, etc..)
12:02 zer0def joined #salt
12:02 Waples_ joined #salt
12:07 babilen eMBee: I typically manage the sources.list entries with apt-formula and pin to a major release and then use https://docs.saltstack.com/en/latest/faq.html#what-is-the-best-way-to-restart-a-salt-minion-daemon-using-salt-after-upgrade for restarting the minion
12:07 babilen (in particular the 'upgrade without automatic restart' followed by 'RESTART USING REMOTE EXECUTIONS')
12:08 AngryJohnnie joined #salt
12:09 babilen The workflow would therefore be: 1. Target new pillar data for the next release to minion 2. Execute "UPGRADE WITHOUT AUTOMATIC RESTART" state and 3. Restart minion with cmd.run_bg
12:10 babilen Ah, 1 ½. would naturally be "Run apt.repositories state to update sources.list entries with data from 1.
12:10 babilen "
12:22 AngryJohnnie joined #salt
12:32 noobiedubie joined #salt
12:38 crux-capacitor joined #salt
12:53 stooj joined #salt
13:06 Psi-Jack haam3r: Hmmmm.. Mayybee. :)
13:14 v12aml joined #salt
13:19 Psi-Jack haam3r: More like, exactly. ;)
13:26 crux-capacitor is there a way to have two of the same module (cmd.run for example) under the same ID in a state?
13:26 haam3r Psi-Jack: good :)
13:26 Psi-Jack Thank you. :)
13:27 Psi-Jack Not entirely sure what the overal differences are to what yo udid and what I was doing is, but, I'll examine that more thoroughly later. :)
13:27 haam3r np :)
13:30 Psi-Jack There's not really a difference in using salt['pillar.get'] and pillar.get directly, is there?
13:31 haam3r From what I remember there at least used to be that you cloud not provide a default value for pillar.get and I think I'm using different grains than you were
13:32 Psi-Jack Hmmm. No, I provide defaults just the same. pillar.get('something:i:want', default)
13:35 haam3r okay good to know
13:40 XenophonF joined #salt
13:44 nixjdm joined #salt
13:46 cgiroua joined #salt
13:46 v12aml joined #salt
13:48 nixjdm joined #salt
13:55 inad923 joined #salt
14:02 basepi joined #salt
14:09 inad924 joined #salt
14:23 exarkun joined #salt
14:23 exarkun left #salt
14:26 dxiri joined #salt
14:28 Psi-Jack Yep. :)
14:35 mikecmpb_ joined #salt
15:00 Hybrid joined #salt
15:01 jcristau joined #salt
15:03 openstacking_123 joined #salt
15:08 obimod joined #salt
15:12 mikecmpbll joined #salt
15:19 obimod might anyone else be experiencing state requisite misordering when using require_in?
15:20 obimod or know of any gotchas related to require_in?
15:21 Cadmus Dear Future People. I fixed my problem by using a shell call to get the 'end' of the redirect, then using that for the source: argument, so salt can see if it's changed
15:21 Cadmus Also I can get the checksum and turn off skip_verify, an option that pains me whenever I find myself using it
15:21 XenophonF Does anyone know what the most recent version of Salt to support Windows XP/Windows Server 2003 is?
15:23 XenophonF the current versions bundle a version of psutil that requires Vista or newer :(
15:24 dmcnabb joined #salt
15:25 XenophonF hm, guess i could look at the git blame output for the requirements file
15:25 cwright joined #salt
15:29 v12aml joined #salt
15:32 relidy joined #salt
15:34 sjorge joined #salt
15:40 v12aml joined #salt
15:43 evle joined #salt
15:54 tiwula joined #salt
15:58 openstacking_123 joined #salt
15:59 AngryJohnnie joined #salt
16:01 pahizz left #salt
16:01 pahiz joined #salt
16:02 pahiz What was it called when you wanted to run some actions when something happens
16:02 pahiz Like when a key gets added
16:02 pahiz Was it events?
16:03 exarkun joined #salt
16:03 Cadmus reactor?
16:03 pahiz Or that
16:03 pahiz Not sure which
16:09 pahiz Ahh so reactor reacts to events
16:30 turring0 joined #salt
16:38 DanyC joined #salt
16:39 DanyC joined #salt
16:48 openstacking_123 joined #salt
16:58 NEOhidra joined #salt
17:01 hiroshi joined #salt
17:06 stooj joined #salt
17:13 Pjusur joined #salt
17:18 pahiz Is there an easy way to use "grains.item ipv4" IP in an .sls file?
17:18 pahiz So that it doesn't choose the localhost IP
17:18 pahiz But the actual IP of the machine
17:18 pahiz Or first non localhost IP
17:20 noobiedubie joined #salt
17:23 miruoy joined #salt
17:25 pmcnabb joined #salt
17:27 crux-capacitor I use a custom grain script that returns a grain containing that specific IP, then I just target that custom grain
17:27 snath joined #salt
17:28 pahiz How do you do that?
17:28 pahiz Also is it possible to use network.ip_addrs as the variable?
17:28 rswett joined #salt
17:28 pahiz In .sls file
17:29 crux-capacitor grain scripts are just python scripts. write one that figures out the "actual IP of the machine", whichever one you are interested in, and returns that in a dictionary called "grains"
17:30 pahiz Sounds pretty difficult
17:30 pahiz For such a simple task
17:30 pahiz Do you know if it's possible to use modules reply as a variable?
17:31 crux-capacitor you can use jinja to set variables in a state like this: {% set my_variable = salt['cmd.run']('command') %}
17:31 pahiz Ahh thanks!
17:31 pahiz That looks perfect
17:32 crux-capacitor sure thing
17:32 mikecmpbll joined #salt
17:33 pahiz Darn, network.ip_addrs returns "<function ip_addrs at ...>"
17:33 crux-capacitor https://docs.saltstack.com/en/latest/ref/states/vars.html#salt
17:33 pahiz Instead of the IP
17:33 crux-capacitor yea you'll probably need to do some parsing either way
17:34 pahiz That blows
17:34 pahiz But thanks anyway
17:42 XenophonF well I manually downgraded to psutil==3.4.2, and now I can run `salt-call --version` on Windows Server 2003
17:42 exarkun left #salt
17:43 XenophonF and the salt-minion service starts now
17:48 XenophonF I can't wait until I get rid of this machine...
17:51 crux-capacitor id love to get rid of ALL windows machines
18:15 noobiedubie joined #salt
18:16 ecdhe joined #salt
18:16 masuberu joined #salt
18:17 zerocool_ joined #salt
18:17 stewgoin joined #salt
18:19 mrueg joined #salt
18:19 bachler joined #salt
18:20 afics joined #salt
18:30 mavhq joined #salt
18:42 Waples_ joined #salt
19:07 schemanic joined #salt
19:10 miruoy joined #salt
19:12 JacobsLadd3r joined #salt
19:12 JacobsLadd3r joined #salt
19:37 openstacking_123 joined #salt
19:58 ponyofdeath joined #salt
19:59 hoonetorg joined #salt
20:01 sugarfree joined #salt
20:05 ecdhe joined #salt
20:38 esteban__ joined #salt
20:59 dendazen joined #salt
21:00 briner joined #salt
21:14 Deliant joined #salt
21:26 Deliant joined #salt
21:36 openstacking_123 joined #salt
21:46 Deliant joined #salt
21:47 openstacking_123 joined #salt
21:56 Trauma joined #salt
21:56 hemebond joined #salt
21:58 jbirdman joined #salt
21:59 dendazen joined #salt
22:05 g3cko joined #salt
22:06 tiwula joined #salt
22:09 zulutango joined #salt
22:26 miruoy joined #salt
22:41 ecdhe joined #salt
22:42 nebuchadnezzar joined #salt
22:45 upb joined #salt
22:45 spiette joined #salt
22:46 rcarlos joined #salt
22:49 froztbyt1 joined #salt
22:49 nebuchadnezzar joined #salt
22:51 hatifnatt joined #salt
22:51 babilen joined #salt
22:51 AvengerMoJo joined #salt
22:51 upb joined #salt
22:51 AssPirate_ joined #salt
22:53 miruoy joined #salt
22:55 snath joined #salt
22:57 sayyid9006 joined #salt
23:01 zulutango joined #salt
23:09 hemebond Anyone tried using Saltstack to update fail2ban bans?
23:19 ponyofdeath joined #salt
23:45 hrumph_ joined #salt
23:52 Edgan hemebond: Seems to slow
23:52 Edgan hemebond: You want to sync the bans across a bunch of hosts?
23:53 hemebond Edgan: Yeah, multiple hosts with the same ban, but also using an external sourfce.
23:53 hemebond *source
23:53 hemebond I know how to do it, was just curious if anyone had done it already.
23:54 Edgan hemebond: I guess you could use the mine to return bans, and a cron to read them all, reconcile them, and then trigger a salt run targeted at fail2ban
23:54 Edgan hemebond: The reactor comes to mind, but how sure how to make it react
23:54 hemebond I'm going to be using Elasticsearch to send alerts/events to Salt which will then ban the IP across multiple servers/apps.
23:55 Edgan hemebond: Why is this even a problem? You have that many hosts exposed to the internet?
23:55 hemebond Web and mail servers.
23:55 Edgan hemebond: elasticsearch seems like extreme overkill
23:56 packeteer joined #salt
23:56 hemebond Overkill? Why is that?
23:56 Edgan hemebond: Why are their ssh ports exposed? No VPN?
23:57 Edgan hemebond: Elasticsearch is a full text search database. I don't think you fail2ban list is every going to get that big, especially if you sanely auto-expire ips from the list.
23:57 hemebond Oh, no I'm banning people trying to find holes (HTTP requests) or login to mail accounts (SMTP logins)
23:57 Edgan hemebond: Also the whole idea seems like overkill. Why centrally manage something that can take care of itself in isolation?
23:58 Edgan ah, not ssh
23:58 Edgan so fail2ban based on http/mail logs
23:58 hemebond Yeah.
23:58 Edgan hemebond: For mail blacklists are probably better and a greylist would probably also be better than fail2ban
23:58 hemebond Currently the SMTP bans are based on the logs, but Elasticsearch has those too.
23:59 hemebond How would blacklists help with SMTP logins?

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