Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2018-03-23

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

All times shown according to UTC.

Time Nick Message
00:31 keldwud joined #salt
00:33 zerocoolback joined #salt
00:33 rlefort joined #salt
00:39 shpoont joined #salt
00:45 shiranaihito joined #salt
01:05 fgimian joined #salt
01:12 masber joined #salt
01:26 cgiroua joined #salt
01:26 cgiroua joined #salt
02:56 ilbot3 joined #salt
02:56 Topic for #salt is now Welcome to #salt! <+> Latest Versions: 2016.11.9, 2017.7.4 <+> RC for 2018.3.0 is out, please test it! <+> 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
03:19 masber joined #salt
03:24 CheckYourSix joined #salt
03:34 keldwud joined #salt
03:44 swa_work joined #salt
04:20 djinni` joined #salt
04:27 zerocoolback joined #salt
04:35 indistylo joined #salt
04:36 kuromagi joined #salt
04:37 Laogeodritt joined #salt
04:37 cyraxjoe joined #salt
04:38 tyx joined #salt
04:38 dezertol joined #salt
04:52 zerocoolback joined #salt
04:58 Guest73 joined #salt
05:11 zerocoolback joined #salt
05:13 aruns joined #salt
05:24 zerocoolback joined #salt
05:35 sauvin_ joined #salt
05:46 gonedungotcluele joined #salt
05:46 zerocool_ joined #salt
06:00 MTecknology I should know this...
06:00 MTecknology Is there any way to do an import   {% import 'foo.lst' ignore missing with context %} and indent everything but the first line?
06:01 MTecknology I remember this being possible, but I can't remember how.
06:02 aruns__ joined #salt
06:09 om2 joined #salt
06:33 Hybrid joined #salt
06:48 indistylo joined #salt
07:03 jas02 joined #salt
07:18 mrueg_ joined #salt
07:24 aldevar joined #salt
07:25 zerocoolback joined #salt
07:40 zerocoolback joined #salt
07:46 Pjusur joined #salt
07:53 heyimawesome joined #salt
07:54 shpoont joined #salt
08:07 tyx joined #salt
08:08 evle joined #salt
08:11 hemebond MTecknology: indent() takes an argument for that.
08:13 Hybrid joined #salt
08:13 hemebond If you want to actually include the file, I do this https://pastebin.com/FLrPj1j9
08:18 Tucky joined #salt
08:20 OliverUK joined #salt
08:27 jas02 joined #salt
08:28 vb29 joined #salt
08:29 vb29 left #salt
08:32 zerocoolback joined #salt
08:32 cewood joined #salt
08:34 jrenner joined #salt
08:43 Guest73 joined #salt
08:45 Hybrid joined #salt
08:48 Ricardo1000 joined #salt
09:08 mikecmpbll joined #salt
09:18 marwel salt-ssh works with git based pillars?
09:19 Hybrid joined #salt
09:19 marwel i just wanted to install salt-minion with a config set by pillars and "salt-ssh box state.apply salt-minion" and "salt box state.appy salt-minion" shows a diff
09:23 marwel interesting...salt-ssh box pillar.items shows me nothing, while salt box pillar.items gives me the correct list
09:24 inad922 joined #salt
09:25 marwel ah ok, i have git cache problems
09:28 jas02 joined #salt
09:28 onslack <msmith> fyi salt-ssh bundles up all the files - including pillar - into a tarball, so pillar should indeed be supported
09:32 marwel thx for the info
09:33 marwel works now, that i've cleared my git cache problems
09:36 jas02 joined #salt
09:41 jas02 joined #salt
09:51 jas02 joined #salt
09:54 jas02_ joined #salt
09:56 nebuchadnezzar joined #salt
09:59 aanriot joined #salt
10:03 jas02 joined #salt
10:17 cro joined #salt
10:26 copec joined #salt
10:26 edrocks joined #salt
10:27 eightyeight joined #salt
10:28 Heartsbane joined #salt
10:28 Heartsbane joined #salt
10:35 shpoont joined #salt
10:38 nebuchadnezzar joined #salt
10:52 Pjusur joined #salt
11:31 evle1 joined #salt
11:39 Pjusur joined #salt
11:40 mavhq joined #salt
11:46 tyx joined #salt
11:50 inad922 joined #salt
11:51 rlefort joined #salt
11:52 mavhq joined #salt
11:55 tyx joined #salt
12:00 tyx joined #salt
12:05 tyx joined #salt
12:10 nebuchad` joined #salt
12:11 Nahual joined #salt
12:11 tyx joined #salt
12:16 nebuchadnezzar joined #salt
12:21 copec joined #salt
12:21 cro joined #salt
12:22 thelocehiliosan joined #salt
12:26 zerocoolback joined #salt
12:27 eightyeight joined #salt
12:34 jas02 joined #salt
12:38 dendazen joined #salt
12:40 englishm_work joined #salt
12:44 Heartsbane joined #salt
12:44 Heartsbane joined #salt
12:49 Heartsbane joined #salt
13:15 Guest73 joined #salt
13:20 XenophonF I wish SaltStack would update the package in EPEL.
13:22 rlefort joined #salt
13:22 jas02 joined #salt
13:25 thelocehiliosan joined #salt
13:32 do3meli joined #salt
13:34 jas02 joined #salt
13:38 weylin joined #salt
13:38 edrocks joined #salt
13:39 jas02 joined #salt
13:45 rlefort joined #salt
13:46 Hybrid joined #salt
13:52 gh34 joined #salt
13:52 CrummyGummy Hi
13:53 CrummyGummy Can anyone see what I'm doing wrong here? https://imgur.com/a/5i0I4
13:54 CrummyGummy Output is     KeyError: '_errors'
13:54 CrummyGummy I'm sure it's something simple but I don't know enough about the jinja stuff
13:56 babilen I don't see that error at all in your screenshot
13:56 babilen Does it happen during state runs?
13:57 babilen If so: Could you paste the entire traceback to one of http://paste.debian.net, https://gist.github.com, http://sprunge.us, … ?
13:57 babilen That looks like an illusive pillar rendering error that has made an appearance recently
13:58 CrummyGummy babilen: yes, the screenshot is the code. Error is some sort of parse error when running state.apply. Wierdly, I use this exact logic somewhere else so I figured it's something simple like formatting.
13:58 CrummyGummy I'll do the files now
14:00 babilen I'm not entirely sure it is due to that error. I've seen that, but its tricky to reproduce and affects different machines
14:00 CrummyGummy https://gist.github.com/waynegemmell/6a0f7776a90813f266db8036b11c15e6
14:01 babilen Would be nice to see the traceback, so that we can check the bugtracker or open a new one if it hasn't been filed
14:01 CrummyGummy added
14:01 babilen Yeah, that's it
14:01 babilen And you can reliably reproduce it?
14:02 CrummyGummy I haven't run it anywhere else but it happens every time. I'll boot up a fresh install quick
14:03 babilen Cheers .. I've seen that error in the last week sporadically and can not reliably reproduce it
14:07 onslack <msmith> which version is that from? it doesn't seem to match 2017.7.4
14:09 aT_ joined #salt
14:11 aT_ left #salt
14:11 cewood joined #salt
14:12 jas02 joined #salt
14:12 CrummyGummy babilen: Looks ok on a clean install
14:12 racooper joined #salt
14:13 tydnA joined #salt
14:13 msmith joined #salt
14:14 babilen WhichWhich version do you use?
14:14 onslack <msmith> that's what i asked :/
14:19 gmoro joined #salt
14:19 CrummyGummy babilen: Now it's back
14:25 Hybrid joined #salt
14:32 jas02 joined #salt
14:33 mage_ any idea for this https://gist.github.com/silenius/51c066fb77f42661aa976dce944b4af0 ?
14:35 dkehn_ joined #salt
14:36 nbari is https://repo.saltstack.com/yum/redhat/salt-repo-latest-2.el7.noarch.rpm down or being throttled ?
14:36 cgiroua joined #salt
14:36 mikecmpb_ joined #salt
14:37 nbari I am getting timeouts while trying to start some minions using this in cloud init: yum install -y https://repo.saltstack.com/yum/redhat/salt-repo-latest-2.el7.noarch.rpm
14:37 DammitJim joined #salt
14:38 onslack <msmith> mage_ you may want to try to render that content without it being interpreted as yaml, just to see what's coming out. i suspect `cp.get_template` with renderer of `jinja` would be sufficient
14:39 onslack <msmith> nbari: works immediately for me, are you having networking issues your end at all?
14:40 mage_ pgbouncer.config is just a dict
14:40 mage_ it works well if I remove the dataabases: section
14:41 nbari working also for me, I think more an issue with the VM's (network)
14:42 jas02 joined #salt
14:45 mage_ ah, it works with |yaml(False)|indent(8)
14:46 tydnA joined #salt
14:49 jas02 joined #salt
14:59 tyx joined #salt
15:14 tiwula joined #salt
15:21 oida joined #salt
15:22 tongpu joined #salt
15:23 _JZ_ joined #salt
15:24 benner left #salt
15:25 Hybrid joined #salt
15:35 Bico_Fino joined #salt
15:45 jas02 joined #salt
15:45 doubletwist I'm wondering if it's worth trying to use a 'roles' grain - given that non-core grains seem to be not considered 'secure'?
15:46 onslack <msmith> the approach i've seen used is careful use of minion id, as that's absolute
15:47 doubletwist Yeah but I worry about the logic for that getting rather convoluted
15:47 jas02 joined #salt
15:47 dezertol joined #salt
15:48 onslack <msmith> that's why i said "careful" :)
15:48 doubletwist heh
15:48 onslack <msmith> some people use short names and character split, some use long names and hyphen split
15:49 doubletwist we have a 15 char limit to hostnames - due to AD limitations.
15:49 onslack <msmith> i'm not talking about hostname. the minion id can be anything
15:49 onslack <msmith> it just happens to default to the hostname if you haven't specified anything else
15:49 babilen CrummyGummy: Sorry, was afk for a while. Would you mind opening a bug report on github? I'd provide details about my problem too and maybe we can find out why this happens
15:50 doubletwist ah
15:50 onslack <msmith> and if you want to keep the hostname, then there's nothing stopping you adding a useful prefix or 5
15:51 doubletwist of course, that doesn't seem any more secure than the grains? Anyone with access to set /etc/salt/grains would also have access to modify /etc/salt/minion, no?
15:52 onslack <msmith> sure, but the instant the minion id changes then the master stops trusting it
15:52 cyberef joined #salt
15:52 onslack <msmith> it does assume that you already have secure key management
15:53 onslack <msmith> if not then all bets are off and you may as well use grains. oh, and put your mother's maiden name in for good luck... ;)
15:54 cyberef left #salt
15:54 cyberef2 joined #salt
15:54 doubletwist Currently [still in development] the keys are just generated at minion 1st start. The minion has the master_finger set. Then we manually do a "salt-key -a <minionid>" on the master
15:58 onslack <msmith> for manual minion addition that's fine. not so much when you need to roll out a few thousand minions automatically :)
15:58 doubletwist Unlikely to need that
15:58 onslack <msmith> some do
15:59 doubletwist We might automate eventually but we're a pet-shop, not a cattle-shop
16:01 doubletwist Roles would be much easier if we could match pillar data from a pillar, or otherwise define 'roles' of some kind from the master.
16:01 mikecmpbll joined #salt
16:03 babilen You can use external pillars and, in particular, pillarstack .. they can be rendered last if you like
16:04 theloceh1liosan joined #salt
16:04 babilen But yeah, I had wanted "static pre-pillars" for a while
16:04 prasant joined #salt
16:05 babilen (same semantics as "normal" pillars and the ability to look up their values in "normal" pillars)
16:05 mikecmpbll joined #salt
16:05 babilen Obviously tricky if you allow non-terminal symbols, so "pre-pillars" would have to be restricted in that regard
16:06 babilen Pillarstack is one approach in that it allows you to define, well, a stack of pillar rendering steps with the ability to refer to data further down the stack
16:06 onslack <msmith> i've seen a pillar top that pulled the role and blindly included something like `role.{{ rolename }}`, whilst using `ignore_missing: true`
16:07 babilen You'd still have to define the role somewhere
16:07 onslack <msmith> handy way to stack complex merging together whilst only supplying the overrides that you need
16:07 onslack <msmith> nope, could be anything. if it doesn't exist then it won't error due to the ignore option
16:07 babilen And this doesn't allow you to do fancy things like "If role_foo is enabled and configure_firewall also: do the configure_firewall_for_role"
16:08 onslack <msmith> sure, you can add multiples. this was just a simple example
16:08 prasant joined #salt
16:08 onslack <msmith> `specific.{{ key1 }}.{{ key2 }}.{{ key3 }}` is still valid
16:08 babilen Well, not really .. you can't easily refer to other pillar data and would have to define roles elsewhere (e.g. in grains)
16:08 edrocks joined #salt
16:09 prasant Urgent help needed guys.. salt minion does not respond if the network connection is reset or restarts on the salt-minion....
16:09 prasant does not respond from master
16:09 Bico_Fino Hello, I have this on /etc/salt/master -> extension_modules: /srv/salt/modules | When I run saltutil.sync_all, all the contents of /srv/salt/modules are deleted. Is that normal?
16:09 onslack <msmith> balilen: if it's that specific then you could include a map and use that :D
16:09 onslack <msmith> prasant: correct, that's the nature of networking :)
16:10 gtmanfred joined #salt
16:10 prasant How can I automatically restart salt minion whenever network restarts?
16:10 onslack <msmith> the minion will reconnect on its own, assuming it hasn't failed completely
16:11 prasant the minion seems to be running without any problems but stops responding...
16:11 pcn Does anyone know what the format is of the 'volume_id' parameter here? https://docs.saltstack.com/en/develop/topics/cloud/aws.html
16:11 prasant so minion has not failed but does not connect to master
16:12 dkehn joined #salt
16:12 onslack <msmith> you've got an either-or situation here. either it reconnects after a retry period or it doesn't, in which case it's failed
16:12 onslack <msmith> neither of which the master can do anything about whatsoever
16:14 doubletwist To make sure I understand, the main security issue with minion-defined grains is that *if* someone gets root access [or otherwise access to change /etc/salt/grains and run a highstate] then that person could change the roles and cause the minion to get configs/data it otherwise wouldn't have access to?
16:14 prasant salt-minion service seems to be running smoothly without any problems... then it should reconnect to the master....
16:14 prasant but it does not
16:14 prasant is there any setting in the minion which will ensure that it retries after sometime
16:14 onslack <msmith> prasant: what's it logging?
16:15 onslack <msmith> that's the default
16:16 onslack <msmith> doubletwist: a malicious user could change a grain, yes, and then gain access to pillar data that they shouldn't be able to, perhaps even including secrets
16:16 onslack <msmith> that's an absolute fail in a secure environment
16:16 doubletwist I wouldn't call our environment "secure" :)
16:17 onslack <msmith> you probably aren't being audited as such either then. auditors seem to revel in "what-if" scenarios
16:18 onslack <msmith> needless to say, if that's not a concern for you then you don't need to defend against it :)
16:19 tvinson joined #salt
16:19 emid joined #salt
16:20 rome_390 joined #salt
16:20 prasant env is not compromised... the network can restart
16:28 MTecknology hemebond: A filter block is what I was looking for.
16:28 prasant guys... stuck... urgent help needed...
16:28 MTecknology hemebond: {% filter indent(width=X) %}{% include foo ... %}{% endfilter %}
16:29 onslack <msmith> prasant: i've already suggested you look at the minion logs. if you can't wait to diagnose the problem then simply restart the minion manually
16:30 onslack <msmith> MTecknology: nice, i'll have to remember that's possible :)
16:30 onslack <scub> Grains are fine if you aren’t using them as the sole means of providing pillar data - the only secure mapping for supplying pillar data is the minion id because you have to reauthenticate with the master in order to change it
16:31 onslack <scub> theres nothing inherently wrong with them, and can prove quite powerful constructs if used safely as described above
16:32 onslack <msmith> well, id isn't the _only_ secure way. cidr is pretty secure too, presuming no-one can come along and plug a machine in to your private network
16:32 prasant logs do not show anything useful...
16:32 prasant how do I increase verbosity
16:33 prasant of logs
16:33 onslack <msmith> <https://docs.saltstack.com/en/latest/ref/configuration/minion.html#log-level>
16:36 babilen doubletwist: That is correct, if you target states/pillars based on grains and this contains sensitive data you don't want all minions to have a minion might change its grains and thereby get access to data it shouldn't
16:38 babilen If an attacker is able to change grains locally on one minion it would allow her to gain access to other bits of data pertaining to others
16:46 doubletwist Is there  a limit to the length of a minion id?
16:47 Sacro Yes
16:48 doubletwist And that is?
16:54 evle1 joined #salt
16:58 onslack <scub> You can change your ip address without having to reauth, i’d say that its not completely accurate to say you can rely on the cidr youre connected to for means of authentication
17:00 wongster80 joined #salt
17:01 ProT-0-TypE joined #salt
17:01 onslack <msmith> i didn't say auth. minion id and key is used for auth. but you can use cidr in a match target. if someone changes a minion's ip address so it's no longer in the same network then it's not going to route traffic and they've probably just bricked it. either way it's not a security issue
17:04 onslack <scub> Which is why I said the minion id is the only secure mapping to providing pillar - relying on addressing to do so is something I wouldn’t do in my environment, specifically because you can change an address without having the reauthenticate with the master. IE: any minion can change its address and get pillar it shouldn’t have, whether or not you route traffic is irrelevant - its the mechanism of forcing reauth for access to pillar that provides the se
17:05 onslack <scub> relying on things that the minion knows about itself to provide pillar data is a dangerous game I don’t plan on playing anytime soon slightly_smiling_face
17:05 onslack <msmith> my point is that changing an ip address doesn't move the minion to a different network. someone would have to unplug it and plug it in somewhere else for that to happen, and if they've got unauthorised physical access to the machine then security is already breached
17:07 onslack <msmith> and i'm not saying that i would use the ip address to provide pillar. i would use the _network_ and proper segregation
17:07 onslack <scub> changing an ip can change your cidr
17:07 onslack <msmith> correct. and if you change it so that the network changes then you can't route to the network you're connected to any more. the end.
17:08 onslack <scub> perhaps in your network configuration at least slightly_smiling_face
17:08 onslack <msmith> i wouldn't deploy a configuration and claim it was secure if it wasn't
17:09 onslack <msmith> port-controlled vlan, non-overlapping segment ranges and strict access control says i can, however
17:10 onslack <scub> Nothing is secure, just takes the right people looking at it - to claim otherwise seems a little short sighted but it seems we’ll just agree to disagree here
17:12 onslack <msmith> fair enough, you don't know that we have restricted logical and physical access, or that we're audited and iso compliant, or indeed any of our security controls
17:13 onslack <msmith> plus, as i'm sure you can tell, we have a team of annoyingly persistent people looking for risks and vulnerabilities :)
17:14 onslack <msmith> needless to say, if i want to get anything past them then i have to have thought of everything or it just doesn't make it to production
17:15 onslack <msmith> and to top it all, now we have gdpr to deal with >;.<;
17:18 masber joined #salt
17:40 doubletwist ok so I think I need some guidance on where to put this pillar data
17:41 doubletwist I'll try to make this make sense :)
17:41 doubletwist So I'm using formulas to set 'selinux' config [mostly permissive, some sensitive servers get enforcing]
17:42 doubletwist And a formula for configuring 'clamav'. But *if* a client is running clamav, then it needs 2 specific booleans enabled in selinux
17:45 exarkun joined #salt
17:46 lordcirth_work doubletwist, so, you have a state that uses pillar vars.  You can do: if clamav, then a=b x=y, else a=pillar(b) x=pillar(y)
17:47 mpanetta joined #salt
17:48 doubletwist Do that where?
17:49 coredumb in yoiur state file
17:51 doubletwist hrm ok
17:51 doubletwist I'll look into it
17:51 doubletwist thanks
17:54 Trauma joined #salt
17:58 prasant joined #salt
18:00 ipsecguy joined #salt
18:06 Deliant joined #salt
18:11 ipsecguy joined #salt
18:16 Nahual Ah the old pillar.item / pillar.get returning different values issue.
18:19 XenophonF two different functions do two different things
18:20 Nahual Yup, but even a refresh is not helping the issue. Seems there a ticket opened on it already though.
18:27 Nahual Alright alright, I blame myself for that one.
18:48 prasant joined #salt
18:53 dkehn joined #salt
18:59 prasant left #salt
18:59 ecdhe joined #salt
19:03 mrueg joined #salt
19:10 inad922 joined #salt
19:12 jesusaur joined #salt
19:21 Mitaka89 joined #salt
19:22 Mitaka89 joined #salt
19:24 __peke__ joined #salt
19:37 jpsharp joined #salt
19:39 jpsharp How do I debug a mysql-based salt pillar?  I've got one box where the pillar works great, but the other box throws a bunch of Jinja errors cause of a missing pillar-based grain.
19:40 jpsharp The debug logs aren't especially helpful.
19:46 ymasson joined #salt
19:56 cewood joined #salt
20:05 major Is there a clean way to pull configured proxy options from the pillar (grabbing state defaults if unset in the pillar?)
20:06 Guest73 joined #salt
20:24 schemanic joined #salt
20:25 schemanic Hello. I have a salt master in AWS, and a local build server. I'm wanting to provision build environments through virtualbox on the build server, but I dont' know how to get it to respond to a remote master. Does anyone have any ideas on this?
20:26 jas02 joined #salt
20:27 Guest73 joined #salt
20:30 jeffspeff joined #salt
20:31 jeffspeff joined #salt
20:46 aldevar left #salt
20:49 keldwud joined #salt
20:58 dendazen joined #salt
21:01 cgiroua joined #salt
21:06 jesusaur joined #salt
21:19 hexa- joined #salt
21:40 chamunks joined #salt
21:42 jholtom joined #salt
21:42 rivyn joined #salt
21:43 straya left #salt
21:43 rivyn I'd like a pillar variable which contains an array of 1 or more versions (float values), to then iterate over within a saltstate using a jinja for loop.  How is this done?
21:43 mikecmpbll joined #salt
21:58 jas02 joined #salt
22:04 Neighbour rivyn: {%- for item in pillar.yourvariable %} ... {%- endfor %}
22:05 rivyn I mean, how would I declare the variable?
22:05 Neighbour in my example, the loop variable is 'item'
22:05 rivyn right now in jinja I have a non-array variable like this:
22:05 rivyn {%- set postgresql_version = salt['pillar.get']('postgresql:version', 10) -%}
22:06 rivyn how would I make it an array of multiple?
22:06 Neighbour do you already have an array, or do you want to make one?
22:06 rivyn I don't have any, I don't know how to make one.
22:06 zer0def in jinja it'd be: {%- set postgresql_version = salt['pillar.get']('postgresql:version', [10]) -%}
22:06 Neighbour {%- set variable = [item1, item2, item3] %}
22:06 zer0def in yaml, wikipedia has awesome examples on how markup language operates
22:06 rivyn ok, square braces, and I assume comma-separated list inside?
22:07 zer0def yeah, strings are quote-wrapped
22:07 rivyn right, cool
22:07 rivyn thanks
22:07 zer0def (you're basically operating with basic python variables in jinja)
22:07 rivyn No experience with python, that's the problem ;)
22:08 ingy zer0def: strings almost never need quotes in yaml
22:08 zer0def yeah, i know they don't in yaml, i meant in jinja
22:08 ingy oh ok
22:09 ingy I see. Sorry for not looking closer there
22:09 zer0def that's 'kay, i frequently the same thing semi-frequently
22:12 zer0def speaking of yaml usage, out of curiosity, does anyone have a cute use case for yaml anchors?
22:15 whytewolf a use for yaml anchors? you like experimenting with dict altering drugs?
22:17 zer0def well, let's just say i made use of them in another situation where yaml was used, but jinja was unavailable
22:17 whytewolf no, just jesting. could be useful if you have to copy the same values between things in the same file. [not sure if you can cross files with them]
22:18 zer0def pretty sure the manner in which salt renders SLS files, i'd need to {% include %}
22:19 zer0def but i guess it's very similar to the `use` requisite
22:21 whytewolf excpet it is happening in your yaml instead of in salt
22:21 zer0def arguably cleaner, unless you don't want to {% include %} other SLS files or `use_in` makes more readibilty sense
22:21 whytewolf so would be useful in say pillar. where you have a ton of dicts and you might need to copy settings around to different places
22:22 whytewolf I would personally just use defaults and merging. but i can see handaling that in pillar directly
22:22 zer0def yeah, i'm just spitballing atm
22:23 zer0def thing about pillar is you could use jinja (with proper care), too
22:23 whytewolf yes you can. that would happen before the yaml even.
22:24 zer0def i'm not sure i have a case where i'd need to have something explicitly happen in yaml and not lowstate, given the order of interpretation
22:25 mikecmpbll joined #salt
22:31 jas02 joined #salt
22:38 shpoont joined #salt
22:42 thelocehiliosan joined #salt
22:44 jas02 joined #salt
22:44 dendazen joined #salt
23:21 nixjdm joined #salt
23:24 jesusaur joined #salt
23:25 Trauma joined #salt
23:32 Trauma joined #salt
23:41 bluenemo joined #salt
23:42 MTecknology 17:07 < onslack> <msmith> correct. and if you change it so that the network changes then you can't route to the network you're connected to any more. the end.
23:43 bluenemo joined #salt
23:43 jesusaur joined #salt
23:43 MTecknology smsith: This assumes that the device can have only exactly one address at a time, which is obviously not the case. Depending on how the pillar selection is written, in most cases, that means a minion can do lots of spoofing. All they need to do is claim an address, it doesn't need to be routable.
23:45 bluenemo joined #salt
23:49 dkehn joined #salt
23:51 shpoont joined #salt

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