Perl 6 - the future is here, just unevenly distributed

IRC log for #salt, 2018-05-02

| 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:00 bluenemo joined #salt
00:03 justanotheruser joined #salt
00:08 ooboyle does anyone see any issues with having a mix of py2 and py3 custom grains sitting in _grains? the theory is that py2 minions won't process the py3 grains and py3 minions won't process the py2 grains. but will that cause problems?
00:11 iggy you can't set a grain as py2 or py3
00:21 ooboyle MTecknology: i know, but a py2 minion won't be able to process a py3 coded grain etc...
00:22 ooboyle sorry that was for iggy
00:27 autolux joined #salt
00:37 iggy so it'll fail and leave tracebacks in your logs
00:37 iggy if you're okay with that, then I don't see why not
00:38 ooboyle yes, oconfirmed with a tes
00:38 cswang joined #salt
00:39 ooboyle i don't love it, but otherwise i need to check for py version and then embed py2 and py3 code in the same grain
00:39 iggy it's really not hard to code things that will work in both
00:39 ooboyle print ?
00:40 ooboyle i have some exception codes written up etc...
00:40 iggy you definitely shouldn't be using print in grains
00:40 hemebond print() is in 2.7 too
00:40 ooboyle good point on that one
00:41 ooboyle i use it for exception codes. it's very helpful
00:41 iggy you monster
00:41 ooboyle erro handling when the think fails
00:41 ooboyle that's what she said
00:41 hemebond Isn't there a module for writing stuff that works in both?
00:42 ooboyle is there?
00:42 hemebond six
00:42 ooboyle i'm doing some non-standard stuff. like reaching out to an s3 bucket to read a json file
00:43 ooboyle hmm... never playted with that
00:43 hemebond You're using Boto for that, yeah?
00:43 hemebond (or even the Salt stuff)
00:44 ooboyle no, via https
00:44 ooboyle urllib
00:45 whytewolf why?
00:45 ooboyle it's complicated
00:46 whytewolf code word for bad design.
00:46 hemebond Well there's no reason you couldn't safely support both versions of urllib in the same script.
00:46 iggy six has a module for urllib
00:46 whytewolf esp, since salt has a built in http lib
00:46 ooboyle i have 1200+ minions across the country at 60 different sites. none of them are the same or have any common references i can use to map them to location. except subnets. which i map to a location number in the json file
00:47 ooboyle ok, might take a look at six and the salt lib then
00:48 ooboyle i think i did look at the salt lib. but it wouldn't work for what i was doing or something
00:49 ooboyle i wrote this a year ago
00:49 ooboyle brain getting old
00:58 Sketch joined #salt
01:18 shiranaihito joined #salt
01:27 exarkun joined #salt
01:41 tiwula joined #salt
01:57 ilbot3 joined #salt
01:57 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:09 masber joined #salt
02:21 stooj joined #salt
02:25 Eugene joined #salt
02:33 cswang joined #salt
02:40 pbuell_ joined #salt
02:44 zerocoolback joined #salt
02:45 zerocoolback joined #salt
02:51 bluenemo joined #salt
02:52 masuberu joined #salt
03:14 zerocoolback joined #salt
03:14 justan0theruser joined #salt
03:39 cswang joined #salt
03:40 justanotheruser joined #salt
04:05 zerocoolback joined #salt
04:06 zerocoolback joined #salt
04:06 zerocoolback joined #salt
04:07 zerocoolback joined #salt
04:08 zerocoolback joined #salt
04:13 cswang joined #salt
04:28 TimA joined #salt
04:30 TimA left #salt
04:31 georgemarshall joined #salt
04:38 timnz joined #salt
04:41 cswang joined #salt
05:00 evle joined #salt
05:15 darioleidi joined #salt
05:22 sauvin joined #salt
05:34 cro joined #salt
05:37 cswang joined #salt
06:07 jab416171 joined #salt
06:09 copec joined #salt
06:10 cbosdonnat joined #salt
06:17 rubenb joined #salt
06:18 colttt joined #salt
06:21 DoomPatrol joined #salt
06:22 cswang joined #salt
06:23 dxiri joined #salt
06:25 Elsmorian joined #salt
06:27 ooboyle_ joined #salt
06:42 Elsmorian joined #salt
06:47 darioleidi joined #salt
06:48 Yoda-BZH joined #salt
06:48 Yoda-BZH joined #salt
06:57 briner joined #salt
06:59 Hybrid joined #salt
07:15 Tucky joined #salt
07:18 savvy9 joined #salt
07:18 Pjusur joined #salt
07:19 savvy9 left #salt
07:26 orichards joined #salt
07:28 Ricardo1000 joined #salt
07:33 awerner joined #salt
07:35 darioleidi joined #salt
07:41 jrenner joined #salt
07:42 rollniak joined #salt
07:53 cswang joined #salt
08:03 tyx joined #salt
08:10 rollniak joined #salt
08:13 MTecknology ooboyle_: I'm not sure why you highlighted me, but my solution would be to write a grain that can support py2 and py3. if sys.version_info[0] < 3:
08:13 bdrung_work joined #salt
08:14 DanyC joined #salt
08:18 briner joined #salt
08:21 Mattch joined #salt
08:22 toofoo[m] joined #salt
08:24 freelock joined #salt
08:24 jerrykan[m] joined #salt
08:31 zerocoolback joined #salt
08:33 briner joined #salt
08:35 briner joined #salt
08:43 Elsmorian joined #salt
08:45 zerocoolback joined #salt
08:46 zerocoolback joined #salt
08:55 cswang joined #salt
09:00 fernie joined #salt
09:02 fernie hi, with 2018.3.0 (py3) trying to do like this in reactor: {% if salt.file.contains('/path/to/file', 'foo'+data.data.bar|string) == True %} , and getting error 'str' object has no attribute 'decode'
09:03 fernie if i remove the conversion |string, error is Can't convert 'int' object to str implicitly
09:03 fernie this worked in 2017.7. so wondering how should the int be converted to string now
09:13 APLU joined #salt
09:13 arlyon joined #salt
09:16 zerocoolback joined #salt
09:20 Elsmorian joined #salt
09:40 fernie hmmh, if i first convert the int to str and then use the converted variable, i get the same error. So seems the problem is not the conversion but the concat of 'foo'+bar
09:42 zer0def could you try `'foo{}'.format(data.data.bar)`?
09:44 demize joined #salt
09:52 fernie zer0def: the same. tried also simply with two string variables and var1+var2 gives that no attribute 'decode'
09:53 fernie guess it has something to do with python3, based on quick google search
09:53 zer0def could you provide a traceback or an issue, if it's already reported?
09:53 Ricardo1000 joined #salt
09:55 fernie not reported yet, tried first asking here if it was something obvious i was doing wrong. I'll create issue with detailed logs and get back later
09:56 zer0def well, a traceback would've been helpful as a start
10:07 cswang joined #salt
10:07 GrisKo joined #salt
10:10 XenophonF fernie: what is data.data.bar?
10:10 XenophonF I can never remember Jinja's precedence rules so two things:
10:10 XenophonF use ~ for string catenation
10:11 XenophonF wrap the concatenated string with parens before piping it to the string filter
10:12 XenophonF e.g., `'foo' ~ data.data.bar` should DTRT
10:12 XenophonF er, strike "string" immediately above
10:12 XenophonF need moar coffee sorry
10:18 fernie XenophonF: its int passed in event to reactor. on mobile now, i'll try that ~ when back on keyboard
10:18 xet7 joined #salt
10:19 fernie and get the traces :)
10:31 fernie here is the trace https://ptpb.pw/Skqq
10:31 fernie zer0def: ^
10:31 fernie XenophonF: also ~ gives the same error
10:37 inad922 joined #salt
10:38 cswang joined #salt
10:40 zer0def so fd.read() returns a unicode string, when .decode() is a bytestring function
10:42 zer0def curious how someone got a byte object, which then mandate the condition in the first place
10:43 zer0def fernie: are you able to use salt-py2?
10:47 fernie zer0def: yes I can make py2 env, I think it should work as it worked with that on 2017.7
10:47 zer0def well, from what i can tell, there's been a huge push to make salt run on py3 and that's probably one of the hiccups
10:48 fernie yeah. I'll get back when have it up and running, need to go away for a while
10:49 zer0def `File "/usr/lib/python3/dist-packages/salt/utils/filebuffer.py", line 91, in next` basically in your case assumes it's dealing with a `bytes` object (a bytestring), when the method from python3's stdlib `fd.read()` returns a `str` object (unicode string)
10:59 Elsmorian joined #salt
11:14 cswang joined #salt
11:17 pbuell joined #salt
11:25 ebbex Can I include a specific list from one pillar into another? I have pillar/users/admins.sls with key users: ['ann', 'bob'], then I have pillar/sudoers/admins.sls, could I reuse the values of users/admins.sls somehow? (There's a catch, I also have users/devs.sls with the key 'users', and pillar_merge_lists: True on salt-master)
11:26 Ricardo1000 joined #salt
11:28 dh joined #salt
11:38 cswang joined #salt
11:49 dendazen joined #salt
11:50 briner joined #salt
11:51 Elsmorian joined #salt
11:59 stewgoin joined #salt
12:12 zerocoolback joined #salt
12:13 systemdave joined #salt
12:14 inad922 joined #salt
12:18 XenophonF ebbex: you can't access Pillar data while rendering Pillar SLS files
12:19 XenophonF well, there's PillarStack but I don't use it so I can't tell you much about it
12:20 XenophonF if you have two lists in Pillar that you want to combine, store them as Jinja instead of YAML, combine them in Jinja, and serialize them to YAML using the |yaml filter as necessary
12:21 zerocoolback joined #salt
12:22 babilen ebbex: Sounds like you want to define the same key sequence in both, but with different values (i.e. entries in a list) while enabling list merging in the master configuration
12:23 babilen https://docs.saltstack.com/en/latest/ref/configuration/master.html#pillar-merge-lists
12:23 babilen If you require logic on "earlier" pillar data you most definitely want to look into pillarstack
12:24 Naresh joined #salt
12:27 mavhq joined #salt
12:27 cswang joined #salt
12:28 CrummyGummy joined #salt
12:32 Nahual joined #salt
12:45 orichards1 joined #salt
12:45 miruoy joined #salt
12:47 ebbex I think I've figured out an approach where I cam use {% include 'users/admins.sls' %} to get it in. But I'll concede that it's not optimal.
12:50 Elsmorian joined #salt
12:50 cgiroua joined #salt
12:57 cswang joined #salt
12:59 tupty joined #salt
13:15 fernie zer0def: oh the py2.. now I remember why tried py3, because of this with 2018.3 and debian9: https://ptpb.pw/vkdj
13:16 Hybrid joined #salt
13:16 onslack <gtmanfred> that is caused by having tornado 5.0 installed with pyzmq <; 17.0.0
13:17 exarkun joined #salt
13:17 onslack <gtmanfred> if you are running from the git branch, there are fixes for those to work, otherwise you should not be using those versions, because they have been marked as supporting versions less than that in the requirements.txt
13:18 babilen ebbex: If really all you want is to merge lists, just define the same key-sequence with different values and let saltstack merge those lists
13:19 fernie gtmanfred: its python-tornado 4.4.3 and python-zmq 16.0.2 from debian packages and salt from salt repo
13:20 fernie gtmanfred: I just added the saltstack repo on clean install and apt install.. if that does not fill the requirements, what does?
13:21 onslack <gtmanfred> hrm, the only way I was able to get that error was with those newer versions :S
13:24 ebbex babilen: I'm only interested in merging lists for the state files. So I can have pillar/top.sls: base: '*': [users.admins, users.devs, users.qa] and a state file that does {% for user in users %} do stuff for users defined in admins, devs and whatever else.{% endfor %}
13:25 racooper joined #salt
13:26 ebbex Then I can have in pillar/top.sls: [sudoers.admins, sudoers.devs], but not qa. And maybe different options for these groups.
13:28 ebbex I think the thing I'm doing is pretty awful, but I'm just writing config that matches what's currently on the systems.
13:29 XenophonF personally, I'd switch from lists to dictionaries
13:30 XenophonF esp. if you're doing for-user-in-users
13:31 inad922 joined #salt
13:32 XenophonF take a look at https://github.com/saltstack-formulas/users-forula for inspiration
13:32 XenophonF (or just use the formula, which I recommend)
13:33 XenophonF e.g., I have two Pillar SLSes that define user accounts, defaults.accounts and salt.example.com
13:33 XenophonF https://github.com/irtnog/salt-pillar-example/blob/master/defaults/accounts.sls
13:33 XenophonF https://github.com/irtnog/salt-pillar-example/blob/master/salt/example/com/init.sls
13:34 XenophonF since that uses a dictionary, everything merges nicely without tricks (maintain lists and merge in Jinja) or extra machinery (PillarStack)
13:35 false joined #salt
13:37 cswang joined #salt
13:39 AngryJohnnie joined #salt
13:45 ooboyle joined #salt
13:45 ooboyle so there's no future module in salt's py3?
13:50 briner joined #salt
13:50 onslack <gtmanfred> what?
13:53 babilen ebbex: Exactly, just make sure you define the same key sequence in users/{admins,devs,qa}.sls ( might want to ensure you use a set in the set)
13:53 babilen ebbex: *use a set in the state (so that you don't render the same user twice)
13:57 ebbex define the same key sequence
13:58 ebbex ?
13:59 ebbex I don't want to repeat the list of users in both users and sudoers though. I just the list in one place.
14:00 edrocks joined #salt
14:02 AngryJohnnie joined #salt
14:05 babilen ebbex: You have "users: - foo\n - bar\n" in users/a.sls and "users: - baz\n - quux\n" in users/b.sls -- salt['pillar.get']('users', []) will get ['foo, 'bar', 'baz', 'quux']
14:06 babilen (if both users.a and users.b are targetted to the same minion and you enabled pillar list merging)
14:06 ebbex babilen: Yup, seems about right.
14:07 babilen Same key sequence 'foo:bar:baz' == 'foo:bar:baz'
14:12 ebbex babilen: yeah, and then i do {% for user in users %} on the users/init.sls state-file. works nicely.
14:14 miruoy joined #salt
14:16 ebbex Now i have similar construct with pillar/sudoers/a.sls, but I don't want to repeat the list already defined in users/a.sls, (what if I add or del users, keeping both files up to date is sure to be prone to errors), so I want some kind of way to include the users/a.sls list into sudoers/a.sls.
14:18 tiwula joined #salt
14:18 ebbex babilen: I ended up with sudoers/a.sls: sudoers: {% macro users() %}{% include 'users/a.sls' %}{% endmacro %} {{ users() | indent(2) }}
14:19 codewaffle joined #salt
14:21 babilen ebbex: Does that work on GitFS (and others?) ?
14:21 babilen But as I said: If you require more than that, look into PillarStack
14:21 dxiri joined #salt
14:22 bluenemo joined #salt
14:22 babilen ebbex: And for sudoers, I wouldn't actually redefine the entire user, but just have "users:$FOO:sudo: True" in there. That way you can easily combine users/a.sls and users/sudoers/a.sls and they'll merge cleanly
14:23 miruoy_ joined #salt
14:23 tupty left #salt
14:33 cswang joined #salt
14:42 edrocks joined #salt
14:43 cgiroua joined #salt
14:51 stooj joined #salt
14:51 DammitJim joined #salt
14:55 GrisKo joined #salt
15:09 Elsmorian joined #salt
15:10 KingJ joined #salt
15:11 CrummyGummy joined #salt
15:17 arlyon joined #salt
15:26 alvinstarr joined #salt
15:28 cswang joined #salt
15:33 oida joined #salt
15:38 zerocoolback joined #salt
15:39 stillLotR joined #salt
15:39 edrocks joined #salt
15:50 dezertol joined #salt
15:54 ExtraCrispy joined #salt
16:07 Hybrid joined #salt
16:09 briner joined #salt
16:13 sjorge joined #salt
16:21 AngryJohnnie joined #salt
16:24 DanyC joined #salt
16:25 DanyC joined #salt
16:28 Edgan ebbex: https://pastebin.com/qRmVVbDN  user creation with salt, but I advocate against this. If you have the chance, use LDAP with pam_mkhomedir, and ssh keys stored in LDAP.
16:31 Edgan ebbex: User creation adds a lot of noise, and user deletion is even worse. Auto created users work out much better. LDAP also lets you turn off access for all systems instantly, where as Salt will never be that faster or efficient.
16:37 sjorge joined #salt
16:41 Trauma joined #salt
16:48 babilen (and you never know where your users might have put SSH keys on systems you remove their accounts from)
16:49 Edgan babilen: Unless you have a way to disable authorized_keys files, they can always do that
16:51 NEOhidra joined #salt
16:52 MTecknology ssh keys seems like a trivial thing to clean up
16:53 Edgan MTecknology: In AWS, with stopped instances, Salt won't touch it. It is also the user, home dir, ssh keys, etc. LDAP storing ssh keys faster and better.
16:53 MTecknology powered off systems, ya.. that's a problem
16:53 Edgan MTecknology: I have seen a company where turnover was so bad that the delete users list in Puppet was 300, and it was 66% of the run time to try to delete all those users.
16:55 MTecknology It bugs me that I didn't get to use AD for user/admin accounts. :(
16:55 MTecknology Not because AD doesn't exist, but because $client didn't think that's how things should be set up.
16:59 cbosdonnat joined #salt
16:59 Edgan AD would not be my first choice
17:00 MTecknology agreed, but it's an existing directory service, why not use it? :(
17:00 jbkc85 joined #salt
17:00 jbkc85 Hi all, is there a way to sha1 encrypt a pillar variable as its passed into state?
17:01 jbkc85 like Ansible has the filters where you can do {{ whatever|hash('she') }}
17:01 Edgan MTecknology: you are saying they already have AD, just not using it with Linux?
17:01 jbkc85 hash('sha1').  Sorry, auto correct
17:01 Edgan jbkc85: There is a way to gpg encrypt pillars
17:01 Edgan jbkc85: sha1 is a one way hash
17:01 MTecknology Edgan: yup, the already have AD, but it's used exclusively for auth backend for web apps
17:02 Edgan MTecknology: web apps, hahaha
17:02 jbkc85 Edgan: I am not looking for the pillar side unfortunately - looking to sha1 encrypt into a file
17:02 jbkc85 Edgan: specific to an application reading the password
17:02 onslack <gtmanfred> jbkc85 you can write a function and sync it to _utils, and add the @jinja_filter decorator to it, and make your own
17:02 Edgan jbkc85: You don't need to reverse it?
17:02 jbkc85 nope
17:02 Edgan jbkc85: Then why wouldn't you just pre-sha1 it?
17:03 jbkc85 was interested to see if Salt could do that for me :-)
17:03 Edgan jbkc85: need the password in the clear and the sha1?
17:03 jbkc85 Option 2 is pre-sha1 it
17:03 Edgan jbkc85: gtmanfred's option is probably the best way
17:04 MTecknology I had an instance once where I wanted plain text passwords stored in pillar. Salt picked a password value from a massive dict and hashed it so the minion was only provided the hashed value.
17:04 jbkc85 indeed.  Thanks for the input everyone!
17:05 nixjdm joined #salt
17:07 cliluw joined #salt
17:10 MTecknology {% from 'sys/centers/emar_keys.sls' import emar_keys %}  {% if center in emar_keys.keys() %}emar_hash: {{ salt['hashutil.md5_digest'](emar_keys[center]) }}{% endif %}
17:11 onslack <gtmanfred> yeah, there are also hash modules in salt that you could just use instead of jinja filters
17:19 jbkc85_ joined #salt
17:21 spiette joined #salt
17:34 Trauma joined #salt
17:36 Nimbus joined #salt
17:36 briner joined #salt
17:47 ymasson joined #salt
17:48 mauli_ joined #salt
17:49 schemanic joined #salt
17:52 schemanic Hello. Does anyone here use rkhunter?
17:53 rivyn joined #salt
17:53 rivyn Is there any difference between grains['grain_name'] and salt['grains_get']('grain_name')?
17:54 * MTecknology grumbles @ http://dpaste.com/1VYT2J9  I can't find anywhere that I specified watch or watch_in incorrectly, but any time this state should be triggered, it fails because the mod_watch state couldn't be found. :S
17:54 MTecknology rivyn: yes, the latter is invalid; the valid form of it will use the salt module, the former is a dict.
17:55 onslack <gtmanfred> rivyn: the latter can also be ‘pathtograins:name’ and can do search deeper into a dictionary with one command, because salt.grains.get refers to a salt module, and grains is just a dictionary that you are pulling data out of
17:55 swa_work joined #salt
17:55 rivyn hmm, well I found the latter by looking at another (working) salt state written by somebody else, which contains:
17:55 rivyn name: deb http://apt.postgresql.org/pub/repos/apt/ {{ salt['grains.get']('lsb_distrib_codename') }}-pgdg main
17:57 AngryJohnnie joined #salt
17:57 schemanic Here is a dumb question: If a user's linux account has a password on it, is that password prompted for when that user uses a passwordless ssh keypair to shell into the host?
17:57 rivyn schemanic: no.
17:57 schemanic rivyn, ergo it's possible to secure the account password entirely separately from placing a password on the ssh keypair. The user wouldn't need to supply two passwords then
17:58 rivyn keep in mind the user can always remove the password from the ssh keypair if they want later.
17:58 rivyn I'm not sure if you can force ssh key logins to require a key with a passphrase or not
17:59 schemanic that's fine with me. My assumption was that I needed to make a passwordless linux account to allow for passwordless keypair auth
17:59 Edgan rivyn: As far as I know you can't, it is handled locally
17:59 rivyn schemanic: you can remove the normal password from the account if you want to require ssh key logins for them.
17:59 schemanic rivyn, I don't think you're understanding me
17:59 Edgan rivyn: You can still require password on sudo though
17:59 deadpoet joined #salt
18:00 rivyn you don't need the account to be passwordless to allow passwordless ssh key logins
18:00 schemanic rivyn, and in that case users just wont be prompted for a password if they ssh into the host?
18:01 rivyn whether the account has a password or not doesn't make a difference.  If the SSH key is passphrase-less, then they won't be prompted.
18:01 schemanic okay cool.
18:01 rivyn the password will only be checked if ssh key authentication isn't possible
18:01 schemanic I see
18:01 schemanic ergo it's insecure if the user somehow tells the server that ssh auth isn't possible, then there's no password in the way
18:02 rivyn it could be, if you actually allowed that to happen.
18:02 rivyn sshd's default config wouldn't allow that to happen
18:02 schemanic right now I'm creating users with salt without passwords
18:02 schemanic I see
18:02 Edgan schemanic: I think sshd auth basically has two tiers. What auth methods you configured sshd to have, and then what you told pam to do. Generally you add things like 2FA via pam. Passwords are handled through pam. Because they could be local accounts, ldap, etc
18:03 rivyn I think the setting for local machine logins requiring a password or not is in /etc/login.defs, but I could be wrong.
18:03 schemanic huh, what do you know? I set a password locally but was still able to ssh in
18:03 schemanic hrm
18:03 rivyn because you used ssh key authentication
18:03 schemanic Okay I have a new problem now
18:03 rivyn which passed, so the password never needed checked
18:03 schemanic I'm creating lots of users on my linux box
18:04 schemanic right now thats all being controlled via pillar
18:04 schemanic I don't really want to know these passwords
18:04 schemanic but I don't want them to be defaults either
18:04 Trauma joined #salt
18:04 schemanic any suggestions for how to let my users determine these values?
18:05 Edgan schemanic: Don't set it via salt, let them login via ssh via key, and set it themselves
18:06 Edgan schemanic: But except for sudo and a few corner cases, do they even need a password?
18:06 rivyn sudo doesn't have to require a password either.
18:07 Edgan schemanic: If it is a public ssh server, you are better off not allowing password auth for ssh
18:07 Edgan rivyn: true, but that is a matter of preference and security
18:07 schemanic Edgan, I'm exploring this because rkhunter is complaining about passwordless accounts in the shadow file
18:07 Edgan schemanic: ignore it
18:07 Edgan schemanic: outdated thought process
18:07 schemanic ...? please elaborate
18:08 Edgan schemanic: ssh keys are more secure than passwords
18:08 schemanic without a password on an account could not an adversary who somehow gains access to the host then log into any account it wishes though?
18:08 Edgan schemanic: and if you don't require passwords for sudo, there is little need for them
18:08 Edgan schemanic: Only if you allow passwordless sudo
18:09 rivyn schemanic: depends on configuration of sudo
18:09 rivyn & su
18:09 schemanic I believe only root can do that
18:09 Edgan schemanic: and if you do require passwords for sudo, then you need passwords
18:09 rivyn I think he's referring to logging in as non-root and then using su/sudo to switch to another non-root user without a password.
18:09 schemanic yes, what rivyn said
18:10 Edgan schemanic: On the flip side, unless you are really on top of security patches, there is almost always a local exploit available that will let them become root without sudo.
18:10 Edgan schemanic: Which is part of the reason passwordless sudo is so common now
18:10 schemanic What we do is allow admins to gain root via a program called rootsh
18:10 schemanic only members of their group can do so
18:11 schemanic other users are part of a separate group without any sudo privileges
18:11 Edgan does it require a password?
18:11 schemanic no it does not.
18:11 rivyn well sudo shouldn't be accessible to just any user, only those in a trusted group.
18:11 schemanic it requires group membership
18:11 Edgan then it is basically sudo
18:11 onslack <gtmanfred> srsly, yeah that is what sudo does
18:11 schemanic I understand your point at a high level I think
18:11 rivyn rootsh must be started via sudo if you want to become root.
18:12 schemanic right. We say `sudo rootsh`
18:12 rivyn rootsh just adds a logging wrapper
18:12 schemanic yes
18:12 onslack <gtmanfred> ahh
18:12 Edgan isn't sudo already logged?
18:12 onslack <gtmanfred> yes
18:12 onslack <gtmanfred> but only the first command
18:12 onslack <gtmanfred> rootsh logs the whole shell
18:12 rivyn sudo su -; do stuff; kill -9 $$   <-- stuff doesn't get logged
18:12 onslack <gtmanfred> so if you do sudo -i, it only logs that you got an interactive shell, nothing else
18:13 schemanic anyway, I do understand that people shouldn't be accessing my servers without ssh keys
18:13 Edgan rivyn: I meant the call of sudo in the first place.
18:13 Edgan rivyn: You want something like auditd to log all commands
18:14 rivyn I imagine auditd and rootsh have some overlap in what they accomplish
18:14 schemanic I have always required that. I wish to suppress the rkhunter warnings though. I am hearing that I can simply set a password with salt to prevent users from logging in as each other, despite them rarely if ever needing to use those passwords. It sounds like it wont be a problem to just pick my own passwords and not tell users.
18:14 rivyn not familiar with auditd
18:15 schemanic auditd doesn't really like rootsh. I wish to kill rootsh at some point
18:15 schemanic but I'm an inheritor so I have to work on what I have time for
18:15 rivyn schemanic: I would think it would be preferable to just not have NOPASSWD: in your /etc/sudoers so that passwordless sudo cannot be used
18:15 Edgan schemanic: no password is not equal to blank password
18:15 rivyn and whatever the equivalent is for su
18:15 Edgan schemanic: and anyone with sudo can become any other user
18:16 Edgan schemanic: no password means no one can authenticate with a password
18:16 schemanic Edgan, why would rkhunter complain about it then?
18:17 rivyn here I was thinking that rkhunter was some coworker of yours this whole time...
18:17 schemanic no. its a simplistic HIDS
18:17 Edgan schemanic: named:!!:17589::::::   !!, the second field is the password from /etc/shadow
18:18 Edgan schemanic: If it was named::, that might be a problem
18:18 Edgan schemanic: Can you show us one of the shadow entries of a user with no password?
18:18 schemanic Are you trying to convince me that there is no need to be concerned about a concept, or that the way I'm trying to achieve a concept is wrong. I understand that passwordless is pretty common. My stated goal is the elimination of the pesky error message.
18:18 rivyn hmm, two exclamation points?  I only have a single one
18:19 Edgan * is also cool
18:19 rivyn service accounts have a * instead of a !
18:19 schemanic someadminuser::17589:0:99999:7:::
18:19 Edgan rivyn: Probably will take anything that isn't the known hash format
18:19 Edgan schemanic: Ah, that would be a problem
18:19 Edgan schemanic: hence why rkhunter is complaining
18:20 rivyn schemanic: stick a ! after the first :
18:20 Edgan schemanic: You used salt to create this user?
18:20 rivyn that will probably lead to the question of how to get salt to do that
18:20 Edgan rivyn: I suspect he didn't create the users with salt
18:20 schemanic Edgan, yes I did
18:20 rivyn did you put password: '' or something?
18:20 Edgan schemanic: Then show us your code, because something went wrong
18:21 Edgan rivyn: Probably something like that
18:21 rivyn here's a passwordless user I created with salt's shadow entry:
18:21 rivyn postgres:!:17652:0:99999:7:::
18:21 Edgan schemanic: Here is some safe user creation salt code, https://pastebin.com/qRmVVbDN
18:22 schemanic http://dpaste.com/3HBJW76
18:22 schemanic this is what I have in my pillar/state
18:22 * MTecknology can't find any reason file.mod_watch isn't being found and throws a rage fit.
18:22 rivyn empty_password: True
18:22 rivyn there's your problem
18:22 Edgan yep
18:22 rivyn "Edgan: schemanic: no password is not equal to blank password"
18:23 Edgan and blank = empty
18:23 rivyn null != ''
18:23 schemanic I see, so empty_password is whats causing the accounts to be created as blank instead of 'without the concept of password'
18:23 Edgan schemanic: just remove that line
18:23 gtmanfred MTecknology: what does your state look like?
18:23 Edgan schemanic: probably don't need the enforce_password either
18:24 gtmanfred both of them
18:24 rivyn user.present - password - A password hash to set for the user. This field is only supported on Linux, FreeBSD, NetBSD, OpenBSD, and Solaris. If the empty_password argument is set to True then password is ignored. For Windows this is the plain text password. For Linux, the hash can be generated with openssl passwd -1.
18:24 schemanic I do not understand. You are saying that what I want is colloquially referred to as 'passwordless', however the documentation text for those parameters says the following:
18:24 MTecknology gtmanfred: http://dpaste.com/3SGEZS7  file.mod_watch is coming from other states that have -watch_in: -file: ferm
18:25 schemanic empty_password
18:25 schemanic Set to True to enable password-less login for user, Default is False.
18:25 rivyn empty_password - Set to True to enable password-less login for user, Default is False.
18:25 rivyn heh
18:25 schemanic yes. I am confused
18:25 rivyn you don't want to enable password-less login, that's what rkhunter is complaining about
18:25 rivyn you want a password-less account that does not allow login
18:25 schemanic but then I *MUST* set an actual password
18:25 rivyn no, you must not
18:26 rivyn the key is that it says "to enable password-less **login**"
18:26 MTecknology system accounts should have no password set, that's not the same as an empty password
18:26 gtmanfred if you do not set a password, and you do not set empty_password: True, then salt should set the password field in /etc/shadow to !!
18:26 rivyn which is what you don't want
18:26 gtmanfred which will make it so that the only way to login to the account is using an ssh key
18:27 rivyn ssh key auth, however, can get into an account that does not have login ability otherwise
18:27 schemanic I see
18:27 schemanic rivyn please elaborate on your last statement
18:27 rivyn none of this has anything to do with ssh key auth
18:27 gtmanfred root can `su - <user>` and doesn't have to provide a password, so it can also switch to that user
18:28 rivyn which can get into an account regardless of whether it has an actual password, empty password, or no password.
18:28 rivyn all it cares about is the ssh key matching
18:28 gtmanfred MTecknology: i don't know
18:28 schemanic that I am not concerned with
18:28 schemanic root users should be allowed to do that
18:29 gtmanfred yes
18:29 gtmanfred but having a password of !! just means password authentication is disabled
18:29 schemanic I just dont want someone who shells in just to do some port forwarding to be able to log into another peer's account
18:30 gtmanfred well, if they can get access to the root user with rootsh, then they can get to that other user using `su -`
18:30 schemanic no I did not speak enough: my non-admin users
18:30 schemanic hmm. setting these values does in my pillar does not go out and correct the issue with salt
18:31 gtmanfred ok great, if they are not admin users they won't be able to login as the other users unless they have access to another authentication method that is not using a password
18:31 gtmanfred s/login/authenticate
18:31 schemanic right. perfect. Thanks for the breakdown
18:35 dendazen joined #salt
18:36 schemanic That has achieved my purposes. Thank you rivyn, Edgan, and gtmanfred!
18:53 crux-capacitor joined #salt
19:04 stooj joined #salt
19:04 * MTecknology groans
19:04 MTecknology I just ran into an issue where I need to make ssh listen on a specific address instead of 0.0.0.0. :(
19:06 vexati0n is there a reason why the Redis cache module keeps telling me "authentication of type 'user' occurred" even when I am absolutely sure the password provided in the config is correct?
19:09 arlyon joined #salt
19:11 doubletwist Ok I know there are multiple ways to do this but I'm unclear on a good 'best practice' way to do it
19:11 doubletwist I've already got a formula that basically installs all of the "common" packages that we require to be installed on all systems
19:12 doubletwist Say I've got another type of system that needs certain other packages installed [but not any other services/configs to manage really].
19:13 doubletwist I'm unclear if I should make another formula or state to handle the app-specific packages? Or add logic tothe pillar for the main formula that installs packages?
19:13 doubletwist Or something else?
19:14 doubletwist Or add logic to the common-packages state?
19:16 vexati0n if it's a one-off situation where there's only ever going to be a single instance that needs this bonus configuration, i'd make it logic inside the main state. if it's a separate class of instance you're going to need more than once, i'd make it a separate state.
19:18 doubletwist ok
19:20 doubletwist Slightly related Q - does it make sense to have role-specific states/formulas that then includes other states along with any role-specific configs/actions?
19:21 MTecknology that sounds a lot like chef logic
19:21 doubletwist Don't know. I've only had experience using rdist, aside from a brief stint testing Puppet
19:22 MTecknology My view is that you're poorly managing state assignments if you have logic of "roles" that isn't dependant on a minion id
19:22 doubletwist Well, the logic in top.sls can call the role formula/state based on the minion id
19:29 rubenb How should one update the Windows minions?
19:30 MTecknology I use salt-cp to push the installer and cmd.run to install
19:31 rubenb The modules, not the states, I assume?
19:32 cliluw joined #salt
19:33 fxhp joined #salt
19:38 jbkc85__ joined #salt
19:43 JacobsLadd3r joined #salt
19:53 arlyon joined #salt
20:01 vexati0n does anyone ever actually use the redis cache module or did someone just slap it together and assume it works?
20:01 vexati0n because i've never had any luck with it, despite the fact that it's exactly what i need
20:05 MTecknology I've been planning to use it in the somewhat near future
20:05 DammitJim joined #salt
20:08 vexati0n i'm trying to get a shared cache, but neither of my 2 masters can even write to it. redis remains completely empty no matter what, even though i know the password and config is correct
20:09 briner joined #salt
20:16 ckonstanski joined #salt
20:19 ckonstanski joined #salt
20:21 cliluw joined #salt
20:22 jdipierro joined #salt
20:26 eightyeight joined #salt
20:32 dxiri joined #salt
20:44 briner joined #salt
20:46 cliluw joined #salt
20:56 doubletwist So this whole 'pillar doesn't merge data' thing is driving me nuts
21:00 bluenemo joined #salt
21:01 dendazen joined #salt
21:09 onslack <mdpolaris> need to add a security group to an existing EC2 instance. Is the proper way to use the boto_ec2.instance_present state module?
21:10 onslack <gtmanfred> you should be able to do that
21:11 MTecknology pillar doesn't merge data?
21:12 onslack <mdpolaris> ok, i didn't see any other boto states that looked correct, i typically use profiles so i will have to duplicate some of that data in the pillar, but i should also create a state to generate those profiles and then the pillar becomes the system of record  slightly_smiling_face
21:13 onslack <gtmanfred> mtecknology, it doesn’t merge lists <https://docs.saltstack.com/en/latest/topics/pillar/#pillar-dictionary-merging>
21:15 doubletwist MTecknology: Well ok, sometimes it merges, and sometimes it overrides. I don't seem to be intelligent enough to understand when/why.
21:16 onslack <gtmanfred> it overrides lists and strings and bools, it talks about it in that doc, under namespace flattening
21:17 onslack <gtmanfred> `The separate pillar SLS files all merge down into a single dictionary of key-value pairs. When`
21:19 doubletwist gtmanfred: I'll go through that doc again
21:20 onslack <mdpolaris> hmmm, ec2_present didn't seem to pickup my SG change, it did nothing
21:21 onslack <mdpolaris> do i need to define all of the parameters or just the ones i want to update?
21:32 dxiri joined #salt
21:35 doubletwist So given the 2 examples here https://paste.fedoraproject.org/paste/P8DdKizJM0wn-gkDdLu03g
21:35 doubletwist The first set will return only tcpdump and mypackage, and the 2nd way will merge the data? Am I understanding that correctly?
22:13 Trauma joined #salt
22:27 ponyofdeath joined #salt
22:37 druonysus joined #salt
22:41 schemanic joined #salt
22:44 dendazen joined #salt
22:50 Deliant joined #salt
23:09 nebuchad` joined #salt
23:12 ixxs joined #salt
23:12 babilen_ joined #salt
23:15 basepi_ joined #salt
23:15 coldbrew- joined #salt
23:15 rideh- joined #salt
23:15 averell- joined #salt
23:16 dlloyd joined #salt
23:17 justanotheruser joined #salt
23:18 exarkun joined #salt
23:21 nledez joined #salt
23:22 pcn joined #salt
23:23 brejoc[m] joined #salt
23:23 jerrykan[m] joined #salt
23:23 J0hnSteel joined #salt
23:23 EvaSDK joined #salt
23:24 Tenyun[m] joined #salt
23:28 mavhq joined #salt
23:29 JacobsLa_ joined #salt

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