Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2018-01-26

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

All times shown according to UTC.

Time Nick Message
00:00 saltslackbridge joined #salt
00:34 threwahway_ joined #salt
00:39 dunny joined #salt
00:39 dunny left #salt
01:06 aviau joined #salt
01:10 aCodinMan joined #salt
01:27 aCodinMan joined #salt
01:29 aCodinMan joined #salt
01:50 pipps joined #salt
02:10 zerocoolback joined #salt
02:33 threwahway joined #salt
02:36 stanchan joined #salt
02:36 threwahway_ joined #salt
02:54 evle2 joined #salt
02:54 threwahway joined #salt
02:54 stanchan joined #salt
02:54 zerocoolback joined #salt
02:56 ilbot3 joined #salt
02:56 Topic for #salt is now Welcome to #salt! <+> Latest Versions: 2016.11.8, 2017.7.2 <+> 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:14 cyborg-one joined #salt
03:15 cyborg-one left #salt
03:25 scooby2 joined #salt
03:32 mk-fg joined #salt
03:32 mk-fg joined #salt
04:01 net0_sysadmin joined #salt
04:06 aCodinMan joined #salt
04:09 justan0theruser joined #salt
04:10 justanotheruser joined #salt
04:11 dendazen joined #salt
04:21 mk-fg joined #salt
04:22 mk-fg joined #salt
04:39 mk-fg joined #salt
04:39 mk-fg joined #salt
04:44 zerocoolback joined #salt
04:53 justanotheruser joined #salt
04:54 zerocoolback joined #salt
04:55 zerocoolback joined #salt
04:56 zerocoolback joined #salt
04:58 zerocoolback joined #salt
04:59 zerocoolback joined #salt
05:03 aCodinMan joined #salt
05:15 threwahway joined #salt
05:15 evle joined #salt
05:17 uptime left #salt
05:21 stanchan joined #salt
05:23 aCodinMa_ joined #salt
05:27 threwahway_ joined #salt
06:00 justanotheruser joined #salt
06:26 threwahway joined #salt
06:27 zerocoolback joined #salt
06:37 threwahway_ joined #salt
06:57 zerocoolback joined #salt
07:06 aCodinMan joined #salt
07:20 Ricardo1000 joined #salt
07:28 yuhl joined #salt
07:29 artur-ba joined #salt
07:31 yuhl left #salt
07:45 aCodinMan joined #salt
08:06 Tucky joined #salt
08:09 aldevar joined #salt
08:22 Hybrid joined #salt
08:25 jas02 joined #salt
08:25 hoonetorg joined #salt
08:26 sybix joined #salt
08:27 jhauser joined #salt
08:34 inad922 joined #salt
08:50 jrenner joined #salt
09:09 pbandark joined #salt
09:09 tracphil joined #salt
09:16 oida joined #salt
09:37 magnus1 joined #salt
09:44 golodhrim joined #salt
09:45 yujunz joined #salt
09:46 aCodinMan joined #salt
10:00 jas02 joined #salt
10:04 Hybrid joined #salt
10:05 yujunz-zte joined #salt
10:07 mattfoxxx joined #salt
10:41 Hybrid joined #salt
10:52 Boulet joined #salt
11:00 yujunz joined #salt
11:05 _val_ Hi everyone. I wanted to add these 2 values in the /etc/security/limits.conf  for elasticsearch. Is there any salt elasticsearch formula?
11:05 _val_ elasticsearch    -       nofile          64000
11:05 _val_ elasticsearch    -       memlock         unlimited
11:15 threwahway joined #salt
11:15 babilen https://github.com/saltstack-formulas/elasticsearch-formula is one
11:16 Creme joined #salt
11:16 _val_ babilen: I have this in the elasticsearch/init.sls http://sprunge.us/YSGd
11:16 _val_ Does this make sense?
11:19 babilen No, there is no "elasticsearch" state .. you'd have to manage that file or append to it. Isn't that done by the packaging?
11:19 babilen (at least on Debian and CentOS)
11:19 babilen /etc/default/elasticsearch / /etc/sysconfig/elasticsearch
11:19 babilen See https://www.elastic.co/guide/en/elasticsearch/reference/master/setting-system-settings.html for information on that
11:19 threwahway_ joined #salt
11:22 _val_ Ohm
11:22 _val_ hmm
11:25 _val_ babilen: Do you have an example on how to write those 2 lines to /etc/security/limits.conf ? Could I use this limits.conf as template and add those 2 values? I don't want to modify the systemd service file
11:30 babilen How are you installing ES?
11:30 babilen (and on which platform)
11:30 _val_ babilen: Centos 7, rpm based
11:31 babilen You don't have to do anything in that case
11:31 babilen https://www.elastic.co/guide/en/elasticsearch/reference/master/setting-system-settings.html#systemd in particular
11:32 _val_ babilen: yes but then I've to do things manually
11:32 babilen Why?
11:32 _val_ This systemctl edit elasticsearch  I don't want to perform that manually
11:33 _val_ I checked the service file of elasticsearch and it is: #LimitMEMLOCK=infinity
11:33 babilen Why would you want to edit that to begin with?
11:33 _val_ When using the RPM or Debian packages on systems that use systemd, system limits must be specified via systemd.  <-- that is what the link you sent says
11:34 babilen Yes and given that you use systemd it's easy to override normal settings, just drop a file with the settings you want to override in /etc/systemd/system/
11:34 babilen You'd never edit the service files that come with the package
11:35 babilen https://www.freedesktop.org/software/systemd/man/systemd.unit.html → Drop-In
11:35 babilen It's very straightforward to make changes to unit files if you have to
11:36 babilen https://manpages.debian.org/stretch/systemd/systemd.unit.5.en.html for example
11:37 _val_ babilen: yeah I know that service files provided by rpm packages shouldn't be modified. It is just hard for me to get around how to use salt to do this
11:37 babilen Basically: Provide a drop-in file in a suitable location (file.managed / file.append) and run systemctl daemon-reload on changes (see requisites)
11:37 _val_ And salt would put it in /etc/systemd/system/...
11:38 saltslackbridge <mts-salt> if you told it to, yes
11:38 _val_ babilen: yeah but that's the point. What is the suitable location. See I have a directory called elasticsearch
11:38 _val_ in there I have the file init.sls
11:38 babilen Please refer to the systemd.unit manpage of your distribution - The logic on drop-in files is detailed there
11:38 _val_ What lines do I add to init.sls so this can get done?
11:40 babilen On Debian: "Along with a unit file foo.service, a "drop-in" directory foo.service.d/ may exist. All files with the suffix ".conf" from this directory will be parsed after the file itself is parsed."
11:40 babilen So elasticsearch drop-in file would be /etc/systemd/system/elasticsearch.service or /etc/systemd/system/elasticsearch.service.d/foo.conf
11:41 babilen Just create a file with suitable content (as detailed in the ES documentation) in that location and trigger daemon-reload on changes
11:41 babilen But read systemd.unit(5)
11:42 _val_ babilen: manually I know how these files work. I write systemd service files daily myself.. but not sure about the syntax how salt does it
11:42 _val_ I found this: https://www.lutro.me/posts/managing-systemd-units-with-salt
11:42 _val_ Does this make sense?
11:43 saltslackbridge <mts-salt> i suspect you're overthinking this. sometimes the simplest solution is the best. you know what file you want to put in manually, so simply use file.managed in salt to put it there
11:43 babilen That's the file.managed / file.append + daemon-reload I refered to, yes
11:43 babilen You literally just drop a file in a specific location
11:44 babilen Or are you not sure on how to manage files with salt exactly?
11:44 babilen I'm not entirely sure where to start with this ;)
11:44 _val_ yes but where do the modifications go?
11:44 _val_ Ok let me just try it first
11:44 babilen Which modifications?
11:45 babilen You have the unit file that comes with the service (which you won't touch) and then anything in the "drop-in" location overrides/adds to the respective settings in the standard unit file
11:46 babilen So, if you have "foo=bar" in the original unit file and "foo=baz" in the drop-in location, then the setting used by the service will be foo=baz
11:46 babilen You'd use salt to perform 2 things: 1. Create/manage a suitable file in the "drop-in location" and 2. Run daemon-reload on changes to that file
11:50 _val_ babilen: Yeaht that is the idea
11:50 _val_ Ok let me check where that suitable location is
11:53 Hybrid1 joined #salt
12:00 threwahway joined #salt
12:04 pualj joined #salt
12:05 yujunz joined #salt
12:06 _val_ babilen: this is what I did: I created this elasticserach_systemd.jinja file with this content: http://sprunge.us/JTAU
12:07 _val_ I changed some values in this file.
12:07 babilen Why?
12:07 babilen That looks like the original unit file
12:07 _val_ no
12:07 _val_ There is a difference
12:07 _val_ and I created this block in my  init.sls
12:07 babilen Well .. the idea is that you'd *ONLY* have the differences in the drop-in file
12:08 _val_ I see. So just 2 lines would suffice?
12:08 babilen So that it is immediately obvious what has changed and that you can still benefit from changes to upstream's unit file
12:08 babilen Yeah
12:08 _val_ let me show you what I changed
12:09 _val_ babilen: I uncommented: #LimitMEMLOCK=infinity
12:09 babilen You need a file such as the *complete example* on https://www.elastic.co/guide/en/elasticsearch/reference/master/setting-system-settings.html#systemd
12:09 babilen You don't uncomment anything
12:09 _val_ and I changed: LimitNOFILE=65535 to > LimitNOFILE=64000
12:09 babilen You just provide a file in the drop-in location with "[Service]\nLimitMEMLOCK=infinity"
12:09 babilen (or whatever change you want to make)
12:10 _val_ Ok let me check that again
12:10 babilen That's the underlying idea of drop-in files... no more "copy and paste" shit that's just bound to bitrot
12:10 babilen The drop-in file complements the original unit file
12:11 _val_ babilen: Alright, starts to make sense.
12:11 _val_ Now my elasticsearch_systemd.jinja file has only these 2 lines:
12:11 _val_ [Service]
12:11 _val_ LimitMEMLOCK=infinity
12:11 _val_ LimitNOFILE=64000
12:11 babilen Pretty much, yes
12:11 _val_ 3 lines.
12:11 babilen Yeah
12:11 _val_ Cool.
12:12 babilen Beautiful, isn't it?
12:12 _val_ babilen: haha. Absolutely!
12:12 saltslackbridge <mts-salt> you don't really need that to be .jinja if there's no template it in
12:12 _val_ I always overcomplicate things
12:12 saltslackbridge <mts-salt> *in it
12:12 babilen And every admin of that box would know right away how the current unit files differs from the original one
12:13 pualj_ joined #salt
12:16 yujunz joined #salt
12:23 _xor joined #salt
12:24 pualj joined #salt
12:35 pualj joined #salt
12:35 DanyC joined #salt
12:42 pualj_ joined #salt
12:46 dendazen joined #salt
12:58 rh10 joined #salt
13:08 nickadam joined #salt
13:12 Nahual joined #salt
13:20 DammitJim joined #salt
13:20 inad922 joined #salt
13:22 aCodinMan joined #salt
13:30 Hybrid joined #salt
13:38 gh34 joined #salt
13:40 Dr_Jazz joined #salt
13:43 _val_ babilen: Another issue:  {{ set elasticsearch = salt['pillar.get']('elasticsearch', {}) }}
13:43 _val_ I get:  Comment: Unable to manage file: Jinja syntax error: expected token 'end of print statement', got 'elasticsearch'; line 22
13:44 _val_ babilen: complete lines are as follow:
13:44 _val_ {{ set elasticsearch = salt['pillar.get']('elasticsearch', {}) }}    <======================
13:44 _val_ Xms{{ elasticsearch.get('heap', {}).get('size', grains.get('mem_total', 1024)/2/1024)|round(0, 'ceil')|int }}g
13:44 _val_ Xmx{{ elasticsearch.get('heap', {}).get('size', grains.get('mem_total', 1024)/2/1024)|round(0, 'ceil')|int }}g
13:45 _val_ what's wrong here?
13:54 dev_tea That should be in a {% %} block, not a {{ }} block
13:54 dev_tea See the description of delimeters in the synopsis here http://jinja.pocoo.org/docs/2.10/templates/
13:57 ws2k3 joined #salt
13:58 Hybrid joined #salt
14:00 tiwula joined #salt
14:06 cablekevin joined #salt
14:07 yujunz joined #salt
14:07 _val_ dev_tea: thanks
14:07 _val_ seemed to work
14:17 Hybrid joined #salt
14:20 inad922 joined #salt
14:21 DammitJim joined #salt
14:29 edrocks joined #salt
14:31 hoonetorg joined #salt
14:35 taylorbyte if i have a dict called services can i do the following filter_by() and reset the same dict {% set service = salt['grains'].filter_by(map.services[service],merge=service) %}
14:36 taylorbyte having set service    and    merge=service  not different variable names
14:36 nixjdm joined #salt
14:47 numkem joined #salt
14:50 cgiroua joined #salt
14:52 JawnAuz joined #salt
14:55 BitBandit joined #salt
15:12 justanotheruser joined #salt
15:22 aCodinMan joined #salt
15:29 floralshoppe joined #salt
15:36 Hybrid joined #salt
15:46 Dr_Jazz joined #salt
15:56 aCodinMan joined #salt
15:57 stduolc joined #salt
16:03 _JZ_ joined #salt
16:15 numkem joined #salt
16:17 anonlizard out of curiosity, what's the community's approach to managing yum repos in an enterprise environment where a variety of yum repos exist?
16:18 anonlizard I'm finding it difficult to find a good(seemingly) approach to repo management -  should repos be added, enabled, disabled within states that manage pkgs or should the repos  be managed by a single(global?) state dedicated to managing said repos
16:19 _KaszpiR_ joined #salt
16:19 Hybrid joined #salt
16:20 saltslackbridge <mts-salt> in general terms, you could have a base state that provides the minimum required, and then have package states that extend the base to add new items. how you do that is up to you but a file.append isn't a terrible approach
16:21 saltslackbridge <mts-salt> another solution may involve using pillar merging to extend a list, and have a single state that applies the list
16:22 saltslackbridge <mts-salt> this is the approach i'm considering for firewall rules, although iptables has multiple lists and ordering matters :slightly_smiling_face:
16:23 saltslackbridge <mts-salt> i suspect a mixture of the two will end up being the solution if only for maintainability
16:25 anonlizard What maintainability issues do you expect?
16:26 saltslackbridge <mts-salt> for a list of repos, none. firewall rules otoh have a habit of biting me so i'm being cautious :slightly_smiling_face:
16:27 davisj anonlizard: I personally use the pillar merging suggested by mts-salt.
16:28 anonlizard aah - i see. btw, thanks salt devs for making this so flexible <sarcasm>
16:28 saltslackbridge <mts-salt> honestly, i like the fact that there's often multiple ways to solve any given problem :slightly_smiling_face:
16:29 davisj an abundance of flexibility can certainly be it's own challange.
16:30 anonlizard yeah, I'm thinking the pillar merging will need to be explored. atm, i dont have an immediate need for that level of functionality, but who knows what the  future may bring - given this is a multi-tennant salt deployment, i can see my app teams utilizing it in the future.
16:32 davisj I'm seeing a strange inconsistency with the salt-minion process name. On all but one minion it is "salt-minion" as seen in /proic/$pid/stat. But on a sinlge machine it is "/usr/bin/python". The os version (centos7), salt version report, and every other variable I can think of are the same on all these machines. Does anyone have an idea why I might be seeing this outlier?
16:32 anonlizard speaking of pillar - should I be using pillar for identities/credentials storage?
16:33 davisj anonlizard: that's what I do.
16:33 davisj Some hook into 3rd party tools like Vault
16:33 davisj Which I believe salt supports as a pillar data source
16:33 anonlizard Do minions have direct view into pillar? specifically, etcd?
16:33 saltslackbridge <mts-salt> beware tho: one gotcha is trusting grains on the minion for dishing out the pillar data. grains can be overwritten
16:34 davisj Yes, but only the data you taget to a particular minion
16:34 davisj affirmative on etcd
16:34 davisj Yeah, don't trust grains too much
16:34 anonlizard thats what im finding out
16:37 anonlizard davis: If i understand you correctly, if a host is targetd (either through top or runtime via salt cli), minions have access to pillar data ony during the state run?
16:37 anonlizard else, no access?
16:37 MTecknology anonlizard: typically- I'd recommend figuring out how to handle it with pillar. Pillar can merge lists, which you should definitely try to make use of. {% for repo in salt.pillar.get('rhel:extra_repos', {} %} rh_repo_{{ repo['name'] }}: repo.enabled: <...> {% endfor %}
16:39 davisj anonlizard: what I mean by targetting, is the pillar data that you assing to a minion in top.sls, isn't visible to other minions. But yeah, by default, I don't think theres any way to access pillar data without executing a salt run.
16:39 saltslackbridge <mts-salt> pillar data is created for a specific minion, yes. minions are given pillar, they don't access it all
16:40 MTecknology minions keep a local copy of pillar in cache
16:40 davisj MTecknology: by default? I thought you had to turn that on.
16:40 davisj I know grain get cached
16:42 MTecknology hm.. I guess I got confused :(
16:42 MTecknology I apparently lied.
16:42 davisj I do that sometimes ;)
16:42 whytewolf it isn't stored in a cache file but it is synced to the minion and stored in memory
16:43 whytewolf https://docs.saltstack.com/en/latest/topics/pillar/#in-memory-pillar-data-vs-on-demand-pillar-data
16:45 Brew joined #salt
16:46 anonlizard whytewolf: thats a handy piece of documentation
16:46 Brew joined #salt
16:47 fatal_exception joined #salt
16:58 DanyC joined #salt
17:00 DanyC_ joined #salt
17:04 szhem joined #salt
17:10 Lionel_Debroux joined #salt
17:13 aCodinMan joined #salt
17:16 mindo joined #salt
17:20 mindo joined #salt
17:21 fatal_exception joined #salt
17:27 aCodinMan joined #salt
17:30 yuhl joined #salt
17:34 pratik joined #salt
17:35 mindo joined #salt
17:36 TheBigNorwegian joined #salt
17:36 hoonetorg joined #salt
17:37 TheBigNorwegian I need a way to remove the CoW flag from a directory of files when I don't know the contents of the directory...is there a better way to loop over files than using a template for...in loop using file.find I can't see?
17:38 mindo joined #salt
17:39 MTecknology that's probably about the best way to do it
17:39 cwright joined #salt
17:39 mindo joined #salt
17:39 MTecknology only half-managing things with salt is never much fun :(
17:40 saltslackbridge <mts-salt> alternatively you can try to write a script command to do it and have salt run that
17:51 yuhl joined #salt
17:56 dstensnes joined #salt
18:20 edrocks joined #salt
18:23 aCodinMan joined #salt
18:24 aCodinMan joined #salt
18:29 pualj joined #salt
18:38 ahrs joined #salt
18:44 uncool joined #salt
18:50 pualj_ joined #salt
19:01 keltim joined #salt
19:02 hax404 joined #salt
19:02 pilatii joined #salt
19:08 ooboyle joined #salt
19:10 ooboyle all: trying to set up publisher_acl so that a user can only install one single package. Is this possible? If so, I can't get the syntax right. e.g.,  user:  - pkg.install salt-minion
19:15 cyteen joined #salt
19:21 ymasson joined #salt
19:22 threwahway joined #salt
19:27 zer0def MTecknology: quick question, since you were responding to TheBigNorwegian, which filesystem has that CoW flag?
19:28 MTecknology I assumed he was referring to copy on write
19:28 MTecknology probably for qcow2 or something, irunno.. just random guess
19:28 DanyC joined #salt
19:28 nomeed joined #salt
19:28 zer0def MTecknology: that's why i'm asking about a filesystem, not a file format
19:29 zer0def i was thinking about using `file.recurse` or something similar to achieve the goal
19:32 DanyC joined #salt
19:32 zer0def i also like how responders draw to overreaching conclusions: https://github.com/saltstack/salt/issues/45699
19:33 zer0def s/ to / /
19:36 jas02 joined #salt
19:40 cyteen joined #salt
20:02 hax404 joined #salt
20:15 aldevar joined #salt
20:16 cyteen joined #salt
20:23 threwahway joined #salt
20:25 pilatii joined #salt
20:27 numkem joined #salt
20:27 sjorge joined #salt
20:33 Hybrid joined #salt
21:12 rh10 joined #salt
21:16 vtolstov joined #salt
21:17 vtolstov hi! how can i skip some block in sls file with jinja templates using file mtime on minion node?
21:18 vtolstov i have 1300 files that only need to be managed when it changed in db, i can't create loop for this files always because it takes significant time to process and i want to avoid this loop when file not changed on remote
21:24 threwahway joined #salt
21:25 cyborg-one joined #salt
21:27 cyborg-one left #salt
21:40 gareth_ joined #salt
21:42 hax404 joined #salt
21:48 chesty joined #salt
21:49 Lionel_Debroux joined #salt
21:52 aCodinMan joined #salt
21:52 aldevar joined #salt
21:54 aldevar joined #salt
21:54 dendazen joined #salt
22:19 kukacz joined #salt
22:25 threwahway joined #salt
22:26 jas02 joined #salt
22:40 Lionel_Debroux joined #salt
22:48 zulutango joined #salt
22:55 Lionel_Debroux_ joined #salt
23:06 pcgod joined #salt
23:09 cyteen_ joined #salt
23:18 cgiroua joined #salt
23:22 jas02 joined #salt
23:25 threwahway joined #salt
23:30 aCodinMa_ joined #salt
23:32 oida joined #salt
23:36 druonysus joined #salt
23:42 dendazen joined #salt
23:46 Lionel_Debroux_ joined #salt
23:59 KevinAn2757 joined #salt

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