2017-12-04T03:26:28 *** dddh_ has quit IRC 2017-12-04T03:31:18 *** okurz has quit IRC 2017-12-04T03:31:40 *** okurz_ has joined #opensuse-admin 2017-12-04T03:31:48 *** okurz_ is now known as okurz 2017-12-04T05:48:37 *** a-865-kx has quit IRC 2017-12-04T05:48:59 *** aboe[m] has quit IRC 2017-12-04T05:49:15 *** aboe[m] has joined #opensuse-admin 2017-12-04T06:03:17 *** a-865-kx has joined #opensuse-admin 2017-12-04T06:20:27 *** Son_Goku has joined #opensuse-admin 2017-12-04T07:16:58 *** Son_Goku has quit IRC 2017-12-04T07:29:30 *** asmorodskyi has joined #opensuse-admin 2017-12-04T07:37:32 *** plinnell has quit IRC 2017-12-04T08:15:19 *** cthugha is now known as ldevulder 2017-12-04T08:34:35 *** solevi_ has quit IRC 2017-12-04T08:44:44 *** mcaj has joined #opensuse-admin 2017-12-04T08:56:00 *** sven15 has joined #opensuse-admin 2017-12-04T09:06:13 *** cboltz has joined #opensuse-admin 2017-12-04T09:06:13 *** cboltz has joined #opensuse-admin 2017-12-04T09:31:16 *** plinnell has joined #opensuse-admin 2017-12-04T09:31:16 *** plinnell has joined #opensuse-admin 2017-12-04T10:46:49 *** kl_eisbaer has joined #opensuse-admin 2017-12-04T10:56:05 *** fvogt has joined #opensuse-admin 2017-12-04T10:59:01 RECOVERY: Hosts syslog on monitor.infra.opensuse.org - OK: Tested /var/log/opensuse/hosts/ - no files older than 240 minutes found ; See https://monitor.opensuse.org/icinga/cgi-bin/extinfo.cgi?type=2&host=monitor.infra.opensuse.org&service=Hosts%20syslog 2017-12-04T11:11:02 *** Son_Goku has joined #opensuse-admin 2017-12-04T11:15:13 *** Son_Goku has quit IRC 2017-12-04T11:21:38 *** Son_Goku has joined #opensuse-admin 2017-12-04T11:26:15 *** Son_Goku has quit IRC 2017-12-04T11:29:40 *** Son_Goku has joined #opensuse-admin 2017-12-04T11:31:31 DimStar: /usr/lib/rpm/suse/macros still has %suse_version 1330 2017-12-04T11:31:50 IIRC it should be updated automatically, so maybe a rebuild of rpm is enough 2017-12-04T11:31:54 cboltz: wait for 1203 to be published 2017-12-04T11:32:09 I triggered a rebuild of rpm yesterday 2017-12-04T11:32:22 ok, thanks 2017-12-04T11:43:44 *** Son_Goku has quit IRC 2017-12-04T11:59:51 *** fvogt has quit IRC 2017-12-04T12:14:13 *** cthugha has joined #opensuse-admin 2017-12-04T12:15:31 *** Son_Goku has joined #opensuse-admin 2017-12-04T12:17:26 *** ldevulder has quit IRC 2017-12-04T12:26:01 *** tigerfoot has quit IRC 2017-12-04T12:31:06 *** Son_Goku has quit IRC 2017-12-04T12:37:01 *** tigerfoot has joined #opensuse-admin 2017-12-04T12:45:53 *** Son_Goku has joined #opensuse-admin 2017-12-04T12:57:17 *** Son_Goku has quit IRC 2017-12-04T13:24:56 *** cboltz has quit IRC 2017-12-04T13:26:35 *** sven15 has quit IRC 2017-12-04T13:27:35 *** sven15 has joined #opensuse-admin 2017-12-04T13:31:55 *** Son_Goku has joined #opensuse-admin 2017-12-04T13:44:24 *** Son_Goku has quit IRC 2017-12-04T13:45:12 *** cboltz has joined #opensuse-admin 2017-12-04T13:45:12 *** cboltz has joined #opensuse-admin 2017-12-04T13:52:54 *** malcolmlewis has quit IRC 2017-12-04T13:58:11 *** Son_Goku has joined #opensuse-admin 2017-12-04T13:58:39 *** malcolmlewis has joined #opensuse-admin 2017-12-04T13:58:39 *** malcolmlewis has joined #opensuse-admin 2017-12-04T13:59:42 *** fvogt has joined #opensuse-admin 2017-12-04T14:19:36 *** Son_Goku has quit IRC 2017-12-04T14:44:27 *** fvogt has quit IRC 2017-12-04T15:05:08 *** kl_eisbaer has quit IRC 2017-12-04T15:47:18 *** kl_eisbaer has joined #opensuse-admin 2017-12-04T15:48:00 Hi kl_eisbaer 2017-12-04T15:48:23 a question about managing logrotate.conf - would it be enough to manage it only on the SLE VMs? 2017-12-04T15:48:33 for the Leap VMs your proposed config won't changed anything ;-) 2017-12-04T15:50:35 cboltz: it's like with everything: sooner or later there will be a change in the default config, while you would still have old machines up and running (switch from xz to XX for example) 2017-12-04T15:50:48 cboltz: in that case it would make sense. ... 2017-12-04T15:51:35 cboltz: IMHO everything that is somehow "running" on the machines should be managed by Salt in the end - and logrotate would be just a simple "copy template file" ... 2017-12-04T15:51:56 same applies for all the files in/below /etc/sysconfig/ 2017-12-04T15:52:02 or /etc/default/ 2017-12-04T15:52:12 ...or everything in /etc ;-) 2017-12-04T15:52:51 * kl_eisbaer is just thinking about /etc/bash.bashrc.local /root/.screenrc and so on 2017-12-04T15:53:20 I'm a fan of touching only things that need to be changed ;-) - that includes getting new (and hopefully better) config files with new openSUSE releases "for free" 2017-12-04T15:54:12 cboltz: ok, in that case just close my request as invalid 2017-12-04T15:54:42 well, for the SLE machines it is valid ;-) 2017-12-04T15:54:49 in that case you can think about a template for /etc/bash.bashrc.local ;-) 2017-12-04T15:55:02 cboltz: for the SLE machines it's just a question when we can get rid of them 2017-12-04T15:55:21 cboltz: I'm working on it, but I'm so damned slow ... 2017-12-04T15:55:31 *** asmorodskyi has quit IRC 2017-12-04T15:55:33 the interesting question is if we get rid of them by a) upgrade to Leap or b) setting up a new machine 2017-12-04T15:56:14 a) _could_ mean to accidently keep the old logrotate.conf if rpm doesn't replace it (maybe it was manually edited, and nobody remembers) 2017-12-04T15:56:22 The machines that I migrated so far are all setup from scratch 2017-12-04T15:57:16 ok, then we can really ignore their logrotate.conf ;-) 2017-12-04T15:57:57 for bashrc.local, I have an idea that not everybody might like: 2017-12-04T15:58:00 set -o vi 2017-12-04T15:58:31 that sets bash to vi mode (for example, "escape k" gives you the previous command) 2017-12-04T15:59:12 cboltz: maybe this should be a decision taken for each machine by the admin ? 2017-12-04T15:59:36 cboltz: IMHO we can offer quite a set of "useful" dot files, but every admin should choose his poison 2017-12-04T15:59:43 indeed, might be an option 2017-12-04T16:00:02 ...which brings me to the question if there is a relationship between users and machines in Salt already ? 2017-12-04T16:00:24 no 2017-12-04T16:00:38 ^ -> bad 2017-12-04T16:00:45 I've seen that you added information about all machines on progress 2017-12-04T16:01:01 well, someone has to start somewhere .... 2017-12-04T16:01:26 just as an idea - we could move this to salt (pillar/id/*) 2017-12-04T16:01:43 cboltz: however you track this in Salt ... 2017-12-04T16:01:45 yeah, I won't complain ;-) 2017-12-04T16:02:10 cboltz: I would love to see the monitoring contacts I'm currently grabbing out of freeipa to be available in Salt 2017-12-04T16:02:26 cboltz: and from there, we could generate the contacts snipplets for the monitoring ... 2017-12-04T16:02:58 pillar/id/ contains a file for each VM, adding the responsible persons etc. there should be easy 2017-12-04T16:03:26 cboltz: jip 2017-12-04T16:03:35 and when that's done, generating the monitoring config is also doable 2017-12-04T16:03:51 cboltz: JFYI I also started to fill out the "hosts" table in freeipa with some information 2017-12-04T16:04:08 :-) 2017-12-04T16:04:23 ...just to see how far we can go with that solution 2017-12-04T16:04:50 I'm a fan of having everything at one place 2017-12-04T16:04:56 but it looks like other than having the mac addresses and some more or less interesting info like "architecture" and "location" maintained in that, there are only hostgroups 2017-12-04T16:05:25 and since salt is already our central point for setting up the VMs, adding more details there would be the best choice IMHO 2017-12-04T16:05:28 I did not really find a way to create a relationship between a machine and the main administrator there 2017-12-04T16:05:36 cboltz: yes 2017-12-04T16:05:57 maybe even the same case for the content I'm currently collecting in the progress wiki 2017-12-04T16:06:16 but there we should see what can go where 2017-12-04T16:06:49 hello 2017-12-04T16:06:56 tampakrap: good morning :-) 2017-12-04T16:07:02 in theory everything can go into pillar/id/ - the "usual stuff" in a machine-/salt-readable form (aka pillar data) 2017-12-04T16:07:11 kl_eisbaer: https://freeipa.infra.opensuse.org/ipa/ui/#/e/group/search we have *-admins groups, that contain users 2017-12-04T16:07:27 and everything else could be added as a comment - or a link to progress, whatever we prefer 2017-12-04T16:07:27 then in salt we have a sudoers rule to allow that group to become root 2017-12-04T16:07:28 tampakrap: and how is that group related to machines ? 2017-12-04T16:08:43 https://gitlab.infra.opensuse.org/infra/salt/blob/production/pillar/role/lists.sls 2017-12-04T16:08:49 We should think about the "lifecycle" of an administrator as well as the lifecycle of a machine... 2017-12-04T16:09:19 tampakrap: ...and how do you find out that a machine is maintained by user X ? 2017-12-04T16:09:51 for me, at the moment, the only "valid" information source is the monitoring 2017-12-04T16:10:02 as we define the nofications for users there 2017-12-04T16:10:17 we don't have 1:1 mapping, I know that the group lists-admins maintains the machine with the role lists, and then I need to figure out with machines belong to the role lists 2017-12-04T16:10:24 but often enough, the "service admins" don't want to get notified about host problems 2017-12-04T16:11:06 That's why I started with https://progress.opensuse.org/projects/opensuse-admin-wiki/wiki/Machines 2017-12-04T16:11:11 FYI: the sudo groups (like "list-admins") are managed in freeipa 2017-12-04T16:11:43 So we have the information about the maintainers now in 4 different tools: 1) freeipa, 2) monitoring, 3) salt, 4) progress 2017-12-04T16:12:04 right, that's 3 more than I'd like ;-) 2017-12-04T16:12:18 not really easy if someone wants to know whom to contact the admin of service X on machine Y 2017-12-04T16:12:51 ...and that makes the roll out of personal settings in the dot files also not easy 2017-12-04T16:13:05 exactly 2017-12-04T16:13:16 (but maybe everybody will love "set -o vi"? ;-) 2017-12-04T16:13:46 maybe someone could provide a cool solution for this problem until the meeting tomorrow ? 2017-12-04T16:13:48 * cboltz wonders if doing a merge request in salt and arguing "you didn't complain about the merge request" is a valid solution 2017-12-04T16:14:06 cboltz: "the one how does something, wins" 2017-12-04T16:14:34 cboltz: but sometimes it will end up in shutting down the salt-minion .... (like I did already on some machines by intention) 2017-12-04T16:15:02 yeah, I don't want to upset people ;-) 2017-12-04T16:15:32 that's why I would love to see a discussion, first ;-) 2017-12-04T16:17:29 *** Son_Goku has joined #opensuse-admin 2017-12-04T16:17:57 if nothing unexpected happens, I probably have some time for a quick draft how we could put all the information that is now spread over 4 places into salt 2017-12-04T16:18:05 most things are candidates for pillar/id 2017-12-04T16:18:24 sudo might also be a candidate for pillar/id if we make it user-based 2017-12-04T16:19:05 if we want to keep it group-based, it will be a separate pillar/$whatever that maps the groups to users 2017-12-04T16:21:08 cboltz: I guess the interesting thing would be to define a contact person for the machine (which might be a "general IT" person) and one for the service on the machine (which most of the time is a list of developers) 2017-12-04T16:21:32 So creating some groups - and putting everyone in such a group might be a good starting point 2017-12-04T16:21:57 a machine should belong to one group for general admin and one or more groups for the running applications 2017-12-04T16:22:21 on community for example, we run the bot, the education and some other stuff on one machine 2017-12-04T16:22:38 ...and most of those services are maintained by different people/groups 2017-12-04T16:22:55 while the machine itself is mostly maintained by me at the moment 2017-12-04T16:23:28 allowing multiple groups per VM should be easy 2017-12-04T16:23:51 ...and then we need to find a script (or a simple web-service) that constructs all the contact persons, either for monitoring or for someone who just wants to have a contact persons Email 2017-12-04T16:24:50 JFYI: => https://monitor.opensuse.org/logs/app/ 2017-12-04T16:25:11 this is currently my playground for an ELK stack 2017-12-04T16:25:44 hopefully I will find the time to do some fine tuning there in the next days 2017-12-04T16:26:40 hmm, that gives me a 404 (as json) :-( 2017-12-04T16:27:08 oh, sorry: please go up one directory ;-) 2017-12-04T16:27:16 https://monitor.opensuse.org/logs/ 2017-12-04T16:27:24 much better :-) 2017-12-04T16:27:35 well, a starting point ;-) 2017-12-04T16:41:47 hi 2017-12-04T16:44:58 *** fvogt has joined #opensuse-admin 2017-12-04T16:44:58 katnip: hi 2017-12-04T16:45:27 hi katnip 2017-12-04T16:45:51 kl_eisbaer: FYI - I just did a highstate on water, so you should start to see log messages from it 2017-12-04T16:46:02 cboltz: merci ;-) 2017-12-04T16:46:06 (actually I echo'd a test message to logger already ;-) 2017-12-04T16:46:22 kl_eisbaer / cboltz: https://paste.opensuse.org/76712453 2017-12-04T16:46:36 cboltz: luckily, the new rsyslog allows to define patterns for machines, instead of defining rules for every machine like the old syslog-ng :-) 2017-12-04T16:47:05 a quick and dirty python script to print admins of a VM based on the role of the VM defined in salt and the memberUids of the $role-admins group on freeipa 2017-12-04T16:47:25 tampakrap: nice :-) 2017-12-04T16:48:15 you can try it with baloo for example 2017-12-04T16:48:19 tampakrap: nice, but I'd still prefer to have the role/group -> admins mapping in salt 2017-12-04T16:48:25 bin/find_admins.py -m baloo 2017-12-04T16:48:30 hennevogel 2017-12-04T16:48:32 pjessen 2017-12-04T16:49:13 cboltz: sure, as long as they are automated (because we need them in freeipa either way as well 2017-12-04T16:49:59 tampakrap: now I need something created like https://paste.opensuse.org/42789925 2017-12-04T16:51:09 * cboltz is AFK for a while for dinner 2017-12-04T16:53:56 cboltz: FYI: rpm -E %suse_version is correct at 1550 now (with rpm from 1203) 2017-12-04T16:57:53 *** Son_Goku has quit IRC 2017-12-04T17:15:28 :-) 2017-12-04T17:19:14 *** sven15 has quit IRC 2017-12-04T17:20:07 hmm, highstate on riesling would remove "remoteip" and "status" from /etc/sysconfig/apache2 APACHE_MODULES 2017-12-04T17:20:17 kl_eisbaer: is this something you added for the monitoring? 2017-12-04T17:26:25 kl_eisbaer: https://paste.opensuse.org/11485627 this will print a dictionary like this: 2017-12-04T17:26:45 {'hennevogel': {'groups': ['lists_admin']}, 'pjessen': {'groups': ['lists_admin']}, 'cboltz': {'groups': ['wiki_admin']}} 2017-12-04T17:27:13 now we have two posibilities: 1) generate a pillar file and inject that data into a dictionary 2017-12-04T17:27:34 2) generate the $contact.cfg files directly with a python script and add them into salt 2017-12-04T17:27:39 as static files 2017-12-04T17:28:33 assuming we go for solution 1 which is what I would prefer, this is the salt code https://paste.opensuse.org/92608471 2017-12-04T17:30:31 cboltz: status of !96 btw? 2017-12-04T17:32:28 it's not 100% complete (see my last comment for the missing parts) 2017-12-04T17:32:48 but it won't break anything if we merge it and salt the missing parts later 2017-12-04T17:33:39 basically some /etc/nrpe.d/* files will stay unmanaged - but they will stay 2017-12-04T17:33:53 and some (already installed) packages aren't listed in salt 2017-12-04T17:34:11 I'd like to have the pillars in profile:monitor:* 2017-12-04T17:34:17 apart from that it's okay for me 2017-12-04T17:37:08 that will cause quite some whitespace change ("only" inside the merge request, but you'll still hate it if you ever need git blame) 2017-12-04T17:39:01 grepping through salt, it seems we don't use the "profile" prefix yet, so - why do you think we need it for monitoring? 2017-12-04T17:40:46 to separate pillars that are used by a formula and pillars that are used by our profile code 2017-12-04T17:43:05 I doubt this is a real-world problem, but still - good argument 2017-12-04T17:54:26 done - I hope I didn't miss anything ;-) 2017-12-04T17:55:56 tampakrap: do you have some time to hunt a gremlin in my test setup? 2017-12-04T17:56:09 I always get Rendering SLS 'production:sssd' failed: Jinja variable 'None' has no attribute 'package' when running a highstate locally 2017-12-04T17:56:52 I don't care too much about LDAP logins in my test setup ;-) therefore I usually simply disable sssd-formula, but it's still annoying 2017-12-04T17:57:39 any idea what could cause this? 2017-12-04T18:07:44 hmm, I found a workaround 2017-12-04T18:09:41 http://paste.opensuse.org/81732757 2017-12-04T18:10:06 actually I no longer wonder why it fails in my test setup - sssd/map.jinja only sets values for Debian and RedHat, but doesn't have default settings (= no settings for openSUSE) 2017-12-04T18:10:15 *but* I wonder why it works on our production setup... 2017-12-04T18:18:38 cboltz: now I do 2017-12-04T18:19:22 in production we use a fork 2017-12-04T18:20:58 ah, that explains it - my formula checkouts default to "master" instead of "production" 2017-12-04T18:21:32 *** malcolmlewis has quit IRC 2017-12-04T18:24:00 *** kl_eisbaer1 has joined #opensuse-admin 2017-12-04T18:24:16 *** malcolmlewis has joined #opensuse-admin 2017-12-04T18:24:16 *** malcolmlewis has joined #opensuse-admin 2017-12-04T18:24:58 *** kl_eisbaer has quit IRC 2017-12-04T18:27:23 and after switching all formulas to "production", I can remove my workarounds again :-) 2017-12-04T18:27:38 cboltz: the pillar.example is wrong 2017-12-04T18:29:56 which pillar.example? It can't be the one from sssd-formula because it doesn't have one 2017-12-04T18:30:50 no I mean the monitoring mr 2017-12-04T18:31:22 ah 2017-12-04T18:31:27 good catch :-) 2017-12-04T18:33:20 it has my thumbs up, merge it whenever you want 2017-12-04T18:35:49 I just pushed the updated pillar.example 2017-12-04T18:36:42 I'll open issues for the missing nrpe.d jobs and package list, and then merge !96 (it's already big enough ;-) 2017-12-04T18:54:14 bonus points if you find a formula 2017-12-04T19:08:18 seems to be a lot going on today, across development 2017-12-04T19:09:16 cboltz: jip, please keep the remoteip (used to gather the "real" external IPs 2017-12-04T19:09:25 cboltz: and status is used for the monitoring 2017-12-04T19:15:11 why are we using the gitlab issue tracker all of the sudden btw? it was supposed to redirect to the redmine tracker 2017-12-04T19:15:28 * tampakrap checks if the redirect is still in place 2017-12-04T19:16:01 https://gitlab.infra.opensuse.org/infra/salt/services/redmine/edit the redirect is there, but apparently the functionality is broken 2017-12-04T19:16:30 kl_eisbaer1: ok, I'll update the wiki salt code 2017-12-04T19:17:02 but I'm not sure if mod_remoteip really changes something - the access logs still look as they always looked 2017-12-04T19:39:34 *** Son_Goku has joined #opensuse-admin 2017-12-04T19:40:08 PROBLEM: MySQL WSREP recv on galera1.infra.opensuse.org - CRIT wsrep_local_recv_queue_avg = 1.700355 ; See https://monitor.opensuse.org/icinga/cgi-bin/extinfo.cgi?type=2&host=galera1.infra.opensuse.org&service=MySQL%20WSREP%20recv 2017-12-04T19:41:49 cboltz: what about !113 and !114? 2017-12-04T19:55:35 I still think they add complexity and overhead without winning anything 2017-12-04T19:56:14 if we really hit conflicts in the future or need to handle .gitconfig etc., we can still add git formula 2017-12-04T19:57:10 but not for "just in case we need it in the future", please ;-) 2017-12-04T19:57:43 I disagree, 4 extra lines in a pillar are not complexity 2017-12-04T19:57:59 don't forget the formula code 2017-12-04T19:58:18 I know it's usually "invisible", but we found bugs in more than one formula 2017-12-04T19:59:05 to me using a formula is like using a library in a scripting language 2017-12-04T19:59:39 *** Son_Goku has quit IRC 2017-12-04T20:01:33 https://gitlab.infra.opensuse.org/infra/salt/merge_requests/125 this will make the tests green again 2017-12-04T20:04:59 nice - looks like you branched for adding the test before I merged the monitoring stuff ;-) 2017-12-04T20:05:09 yes 2017-12-04T20:07:57 can you make that test a bit more strict? 2017-12-04T20:08:16 at the moment, a file name "examplesls" would pass 2017-12-04T20:08:27 checking for "\.sls" would be a good idea ;-) 2017-12-04T20:09:12 okay 2017-12-04T20:13:27 done 2017-12-04T20:13:58 next step would be to validate if our ruby and python scripts are validating 2017-12-04T20:14:06 s/validate/check 2017-12-04T20:17:37 okay it failed again lol 2017-12-04T20:17:53 ah no !125 failed 2017-12-04T20:18:44 !124 sorry 2017-12-04T20:18:46 so we're fine 2017-12-04T20:19:44 cboltz: I'll insist about the git formula, I find it a good idea and I don't think it adds complexity. I believe it makes things more clear and I'm willing to remove it the moment it creates an issue 2017-12-04T20:19:53 but it won't create an issue, quite the opposite 2017-12-04T20:20:12 it will stay in a dark corner without annoying anybody 2017-12-04T20:23:09 sounds like I need to prepare a bigger "told you so" sign. Just in case, you know? ;-)) 2017-12-04T20:23:20 challenge accepted 2017-12-04T20:23:40 may I add an unrelated condition? ;-) 2017-12-04T20:23:52 your zypper-formula uses {{ package }}: as state name 2017-12-04T20:24:08 and I had to work around that a few times 2017-12-04T20:24:31 can you change that to something like zypper_pkg_{{ package }}: and add - name: {{ package }} ? 2017-12-04T20:25:13 I don't get the problem sorry 2017-12-04T20:25:34 let's say I install a package using zypper:package pillar 2017-12-04T20:25:47 and then want to add a service.running 2017-12-04T20:25:57 often service name == package name 2017-12-04T20:26:28 but zypper-formula already "blocks" that state name, so I have to use - name: for the service 2017-12-04T20:27:07 see salt/profile/wiki/apache.sls for a real-world example 2017-12-04T20:27:37 the point is that if a package has a service, we shouldn't have it in common.sls but in a formula or profile code (that should go to a formula at some point) 2017-12-04T20:28:20 so it would be better if we create a profile/web/server/apache.sls to handle apache related stuff (or use an official apache formula, which is a bigger task) 2017-12-04T20:29:29 nevertheless zypper-formula should use state names in its "namespace" (starting with "zypper") IMHO 2017-12-04T20:31:13 I disagree sorry 2017-12-04T20:38:37 cboltz: https://github.com/tampakrap/zypper-formula/commit/6448409924ccec70c2be27d53178208faa949e28 2017-12-04T20:40:34 you'll also need to add - name: {{ package }} 2017-12-04T20:40:50 but besides that, I'm happy that I could convince you ;-) 2017-12-04T20:41:42 ah no, my point remains 2017-12-04T20:42:36 the fact that we may get duplicate identifiers because of the package name is another point, that I agree with you 2017-12-04T20:42:58 https://github.com/tampakrap/zypper-formula/commit/70c252c69685dace4831f8d62b962b57e6626f59 better? 2017-12-04T20:43:30 yes, looks good :-) 2017-12-04T21:00:26 FYI: olaf.infra.opensuse.org is now life as scanner and fills mirrordb1 via the pgbouncer on anna 2017-12-04T21:01:21 yey!! 2017-12-04T21:01:49 :-) 2017-12-04T21:03:52 tampakrap, cboltz: I leave it up to you guys to implement the "pgbouncer", "pg_repack", apache, nginx... and other stuff in Salt ;-) 2017-12-04T21:04:48 okay! 2017-12-04T21:05:13 Tomorrow I like to get the "knappsack" stuff up and running on olaf 2017-12-04T21:05:27 I gave olaf 10 CPUs for this - hoping that this is enough 2017-12-04T21:06:18 the good thing is, that we will get some control over that stuff this way :-) 2017-12-04T21:07:23 as ancorgs has already a heroes account, I hope he can help me with the setup :-) 2017-12-04T21:07:25 *** raffo has joined #opensuse-admin 2017-12-04T21:08:24 tampakrap: but it might be that we need to give aplanas also an (VPN) account 2017-12-04T21:08:51 same for lnussel, if he does not have one, yet 2017-12-04T21:09:14 ludwig has, I'll do alberto tomorrow 2017-12-04T21:09:25 tampakrap: thanks! 2017-12-04T21:19:01 *** nicolasbock has joined #opensuse-admin 2017-12-04T21:38:54 kl_eisbaer1: what does Check_MK inventory is WARNING / WARN - 1 unmonitored services (ps:1)(!), no vanished services found want to tell me? (seen for riesling and water) 2017-12-04T21:39:17 cboltz: that means that there is a new service disovered, that is currently not monitored 2017-12-04T21:39:45 "ps:1" indicates, that there is a new process, that I currently just "monitor" via ps 2017-12-04T21:39:46 it would be helpful if the warning includes the service name ;-) 2017-12-04T21:40:06 cboltz: file an upstream bug at check_mk, please ;-) 2017-12-04T21:40:40 I could eleminate that "additional service check" check and let the autodiscovery do it automatically 2017-12-04T21:40:54 but that way we would not notice if something on a machine changes 2017-12-04T21:41:14 if - for example - a filesystem is not mounted any longer 2017-12-04T21:41:44 the current way is ok, I just wondered about the not-so-useful warning mail ;-) 2017-12-04T21:42:06 for reporting it upstream - I'll leave that to you 2017-12-04T21:42:14 call it the price tag for salting the monitoring ;-) 2017-12-04T21:42:15 well - at least it started to interest you ;-) 2017-12-04T21:43:09 cboltz: ;-) 2017-12-04T21:43:39 * kl_eisbaer1 is currently playing with using huge kernel pages for postgres :-) 2017-12-04T21:45:33 funny, how easy you can run out of memory with this :-) 2017-12-04T21:48:47 ...and also funny how easy you could create (and destroy) slaves via repmgr 2017-12-04T21:49:41 cboltz: btw - the check tells you exactly what is missing 2017-12-04T21:49:45 => unmonitored: ps: proc_Rsyslog Process 2017-12-04T21:49:58 https://monitor.opensuse.org/icinga/cgi-bin/extinfo.cgi?type=2&host=riesling.infra.opensuse.org&service=Check_MK+inventory 2017-12-04T21:50:16 might be that the Email just does not contain the $LONG_CHECK_OUTPUT 2017-12-04T21:50:42 exactly, the mail doesn't include this :-( 2017-12-04T21:51:10 is this something you could change? 2017-12-04T21:51:14 cboltz: just re-configure this via Salt, please ;-) 2017-12-04T21:52:44 the monitoring server is mostly unsalted, so I'll grant you an exception to change this manually ;-) 2017-12-04T21:52:46 ^ -> fixed 2017-12-04T21:53:24 hm: should I change that setting also for our IRC bot ? 2017-12-04T21:54:06 how long can $LONG_CHECK_OUTPUT be in worst case? 2017-12-04T21:54:43 4 kB 2017-12-04T21:58:31 rfc2812 (IRC) says messages SHALL NOT exceed 512 characters in length, counting all characters including the trailing CR-LF so 4kB might be a bit too much ;-) 2017-12-04T21:59:11 I do not expect more than 1 kB - but ok, in this case we leave it with the old settings for IRC 2017-12-04T21:59:12 but hey, they didn't write MUST NOT ;-) 2017-12-04T22:04:07 na, don't spam here too much. Interested users could click on the URL anyway 2017-12-04T23:05:08 *** kl_eisbaer1 has left #opensuse-admin 2017-12-04T23:24:12 *** Son_Goku has joined #opensuse-admin 2017-12-04T23:30:11 *** fvogt has quit IRC