- Heroes

[heroes] Postfix not installed on newer VMs
by Christian Boltz 15 Jul '19

15 Jul '19

Hello, TL;DR: should all VMs - have postfix installed and running - have the alias root -> admin-auto(a)o.o - have a common /etc/postfix/main.cf (or at least some specific options like relayhost) ? Longer version: I noticed that 15 of our VMs don't have postfix installed. This seems to affect the "newer" servers (created with 42.3 and 15.x JeOS). The older VMs have postfix installed, even if they were upgraded in the meantime. My guess is that this is caused by a change in the patterns so that JeOS no longer includes postfix. Now the question is - should we have postfix running everywhere? I'd say yes because it's for example needed to let cron send out mails. On a related note - only 16 VMs forward root mails to admin-auto(a)o.o - IMHO that's also something all VMs should do. And finally, we'll need to set the relayhost (relay.i.o.o) in main.cf everywhere [1] [2] Of course there are some obvious exceptions from "all servers" - anna and elsa _are_ relay.i.o.o and therefore shouldn't get the relayhost setting. Does the above sound like a good idea? If so, I'll prepare a MR to do this with salt. (Just in case - if nobody answers within a week, I'll also do it ;-) BTW: If you are interested in the raw data behind this mail, you can find the main.cf of all servers in ~cboltz/postfix-configs/ on minnie.i.o.o. Regards, Christian Boltz [1] Maybe we should even deploy a common main.cf to all servers, but a quick comparison of the main.cf files we have shows that they all differ, so coming up with a common main.cf might be interesting[tm]. (besides anna and elsa, baloo will probably also have to keep its special main.cf) [2] On the positive side, all servers (except anna and elsa) that currently have postfix installed also have the relayhost set - probably because that was done in the JeOS config.sh script. -- "Oh my god, nobody has improved the shape of the wheel since 100 years. Let's abandon all wheels immediately, they cannot possibly work anymore!!!" [Stefan Seyfried in opensuse-factory] -- To unsubscribe, e-mail: heroes+unsubscribe(a)opensuse.org To contact the owner, e-mail: heroes+owner(a)opensuse.org

2 2

[heroes] Re: Post to opensuse-packaging@opensuse.org denied: %{python3_sitelib} broken on CentOS_7
by Sebastian 08 Jul '19

08 Jul '19

Dear Admins, I tried to post to opensuse-buildservice and opensuse-packaging, but got denied both times. I am subscribed to both lists and I can't figure out any other reason why the mail get's denied. How can I post to these lists? Sebastian On 08/04/2019 11.09, opensuse-packaging+owner(a)opensuse.org wrote: > Hi, this is the Mlmmj program managing the > <opensuse-packaging(a)opensuse.org> mailing list. > > The message from <sebix(a)sebix.at> with subject "%{python3_sitelib} broken on > CentOS_7" was unable to be delivered to the list because of an access rule > set up by the list administrator. > > (The denied message is below.)

3 3

[heroes] I need the virtual maps updated for a new mailing list - who does that?
by Per Jessen 04 Jul '19

04 Jul '19

I need to add a mailing list to the virtual maps, Theo used to do it as I didn't or don't have the right access. https://progress.opensuse.org/issues/51548 thanks Per -- Per Jessen, Zürich (22.4°C) Member, openSUSE Heroes -- To unsubscribe, e-mail: heroes+unsubscribe(a)opensuse.org To contact the owner, e-mail: heroes+owner(a)opensuse.org

5 9

[heroes] Reminder: Heroes meeting on Tuesday
by Christian Boltz 30 Jun '19

30 Jun '19

Hello, here's the usual reminder that we'll have a meeting on Tuesday (2019-07-02) at 18:00 UTC / 20:00 CEST in the #opensuse-admin IRC channel. See https://progress.opensuse.org/issues/52565 for the planned topics, and feel free to add things you want to discuss. Regards, Christian Boltz -- > Aber sorry, habe die Schnauze voll mit Linux.... Da gehört's eindeutig nicht hin. Nimm's lieber wieder raus. [> Juergen Jaeckel und Bernd Glueckert in suse-linux] -- To unsubscribe, e-mail: heroes+unsubscribe(a)opensuse.org To contact the owner, e-mail: heroes+owner(a)opensuse.org

1 0

[heroes] Removed keyserver from monitoring
by Karol Babioch 30 Jun '19

30 Jun '19

Hi all, since the monitoring has been complaining about the keyserver being down for months and it is unlikely that it will ever come back in its current form, I've removed the service along with all services from our monitoring. I need to double-check if the VM is still lying around, but probably it can also be wiped and the resources made available again. Any objections? Best regards, Karol Babioch

1 0

[heroes] [RED] rsync.opensuse.org down
by Thorsten Bro | openSUSE Heroes 28 Jun '19

28 Jun '19

Hi all, unfortunately I have to inform you, that rsync.opensuse.org is down since this evening ~17.00 CEST. The machine is a server which was donated by SUSE Linux GmbH. The rack space, power and uplink was donated by QSC AG datacenter in Nuremberg (former IP-Exchange). What happened: I tried to do a kernel update of the machine and now it doesn't come back to life. As this machine is in an external DC, we need to drive there, as we don't have out-of-band-management possibilities in the sponsored rack of QSC AG. What's the impact of this: rsync.opensuse.org is down, which means that all unauthorized rsync-mirrors of openSUSE (which are not in the whitelist on stage.opensuse.org) are not able to sync from us at the moment. Furthermore rsync.opensuse.org is used as first push mirror usually by the OBS, which means that all clients which access download.opensuse.org via HTTP get redirected to rsync.opensuse.org by mirrorbrain, as long as the other servers in the world are syncing the newest updates and have it not yet ready. In summary: - non-whitelisted rsync-mirrors can't mirror at the moment - Users will feel a performance drop for installing and downloading updates because they are redirected to downloadcontent.opensuse.org, the mirror in our office datacenter in Nuremberg with limited Uplink capacities, until other mirrors and the scanning caught up with the changes. - This affects -indeed- every package updated in the OBS which is not published below this path: https://download.opensuse.org/repositories/ - including Updates, Tumbleweed and Leap snapshots Mitigation: In the end, running this on an old SUSE-donated machine with a lot of spinning slow disks, is not matching the performance needs of the machine. So there need to be a final and well-engineered solution for this. Which was, until now, always out of scope of any budget. As a quick fix, somebody needs to drive to the data centre and investigate the machine. I'm willing to help, but I'm not driving those 60km again on my private expense, as I did last time. Sorry. On behalf of the openSUSE Heroes team. Best regards, -- Thorsten Bro <tbro(a)opensuse.org> - Member of openSUSE Heroes - -- To unsubscribe, e-mail: heroes+unsubscribe(a)opensuse.org To contact the owner, e-mail: heroes+owner(a)opensuse.org

6 8

[heroes] FYI: countdown.o.o served from new server
by Christian Boltz 24 Jun '19

24 Jun '19

Hello, since about an hour, countdown.opensuse.org gets served from a new server. In theory everything should just continue to work. There are even some small improvements: - I fixed a config bug that prevented serving images in languages your browser doesn't like, see https://progress.opensuse.org/issues/36213 for details. - The cronjob now does "git pull" hourly so that all changes on github get auto-deployed. - Oh, and the setup is fully salted now :-) If you notice any problems, please tell me or send a mail to admin(a)o.o to open a ticket. Note: I updated the haproxy config on anna, but I'm not sure if the sync to else works. (I'm afraid the answer is probably "no".) I'd love to maintain the haproxy.cfg in salt (and maybe even auto-deploy it on anna/elsa?), but as long as a "state.highstate test=True" shows me pending changes to /etc/keepalived/keepalived.conf which I don't understand, I hesitate to run a highstate ;-) (AFAIK these changes are from https://gitlab.infra.opensuse.org/infra/salt/merge_requests/232 ) In other words: can someone who knows keepalived please check if these changes look valid and then run a highstate on anna and elsa? When done, please close https://progress.opensuse.org/issues/46592 Regards, Christian Boltz -- [Cyberwehr] Für die Teilnehmer gibt es dann je erlegtem Trojaner ein Malwareabschuss-Abzeichen und ab 10 Stück das Cyberkreuz am Cat5-Kabel. [Martin Seeger zu https://plus.google.com/+KristianKöhntopp/posts/VbiRrRwX8rF] -- To unsubscribe, e-mail: heroes+unsubscribe(a)opensuse.org To contact the owner, e-mail: heroes+owner(a)opensuse.org

1 0

[heroes] NNTP questions
by George Baltz 20 Jun '19

20 Jun '19

Is there any interest in resurrecting the NNTP access to the forums? Anyone else asking for it? I was a news server admin in the distant past (1992-99), and have a little time to devote to scraping the rust off my admin skills. What sort of resources were used? Is there an image of the old server? Was it stock INN, or customized? Was the gateway built in house? Any doc/info on this particular setup available? I'm not sure of the demand/effort requirements for the service, but I'd like to look into it. -- To unsubscribe, e-mail: heroes+unsubscribe(a)opensuse.org To contact the owner, e-mail: heroes+owner(a)opensuse.org

7 21

[heroes] download.opensuse.org timing out tonight
by David Kronlid 19 Jun '19

19 Jun '19

Hi heroes, The repos are timing out constantly for me tonight, making it difficult and unreliable to use zypper, doing upgrades or doing distro upgrades online. I just created a bug report: https://bugzilla.opensuse.org/show_bug.cgi?id=1138761 Thought I should let you know in case someone has time to check if it's mirrorbrain or some mirrors that aren't working like they should. Good luck finding the cause! David -- David Kronlid Tel/Signal: +46-73-2022910 GPG: 0x1F34502F -- To unsubscribe, e-mail: heroes+unsubscribe(a)opensuse.org To contact the owner, e-mail: heroes+owner(a)opensuse.org

2 3

[heroes] history ?
by Per Jessen 19 Jun '19

19 Jun '19

Can anyone enlighten me - what is the purpose of the stuff we keep in /srv/ftp/pub/opensuse/history/ : drwxr-xr-x 3 tumbleweed-snapshot tumbleweed-snapshot 91 May 12 18:00 20190509/ drwxr-xr-x 3 tumbleweed-snapshot tumbleweed-snapshot 91 May 13 17:00 20190510/ drwxr-xr-x 3 tumbleweed-snapshot tumbleweed-snapshot 91 May 15 23:00 20190512/ drwxr-xr-x 3 tumbleweed-snapshot tumbleweed-snapshot 91 May 18 18:00 20190514/ drwxr-xr-x 3 tumbleweed-snapshot tumbleweed-snapshot 91 May 20 15:00 20190516/ drwxr-xr-x 3 tumbleweed-snapshot tumbleweed-snapshot 91 May 20 23:00 20190517/ drwxr-xr-x 3 tumbleweed-snapshot tumbleweed-snapshot 91 May 21 23:00 20190520/ drwxr-xr-x 3 tumbleweed-snapshot tumbleweed-snapshot 91 May 22 23:00 20190521/ drwxr-xr-x 3 tumbleweed-snapshot tumbleweed-snapshot 91 May 25 23:00 20190524/ drwxr-xr-x 3 tumbleweed-snapshot tumbleweed-snapshot 91 May 27 23:00 20190525/ drwxr-xr-x 3 tumbleweed-snapshot tumbleweed-snapshot 91 May 29 02:00 20190527/ drwxr-xr-x 3 tumbleweed-snapshot tumbleweed-snapshot 91 Jun 2 16:00 20190529/ drwxr-xr-x 3 tumbleweed-snapshot tumbleweed-snapshot 91 Jun 3 21:00 20190601/ drwxr-xr-x 3 tumbleweed-snapshot tumbleweed-snapshot 91 Jun 5 20:00 20190603/ drwxr-xr-x 3 tumbleweed-snapshot tumbleweed-snapshot 91 Jun 6 03:00 20190604/ drwxr-xr-x 3 tumbleweed-snapshot tumbleweed-snapshot 91 Jun 7 02:00 20190605/ drwxr-xr-x 3 tumbleweed-snapshot tumbleweed-snapshot 91 Jun 8 00:00 20190606/ drwxr-xr-x 3 tumbleweed-snapshot tumbleweed-snapshot 91 Jun 9 17:00 20190607/ drwxr-xr-x 3 tumbleweed-snapshot tumbleweed-snapshot 91 Jun 16 01:00 20190612/ drwxr-xr-x 3 tumbleweed-snapshot tumbleweed-snapshot 91 Jun 18 05:00 20190614/ -rw-r--r-- 1 tumbleweed-snapshot tumbleweed-snapshot 27 Jun 17 22:15 disk -rw-r--r-- 1 tumbleweed-snapshot tumbleweed-snapshot 9 Jun 17 22:14 latest -rw-r--r-- 1 tumbleweed-snapshot tumbleweed-snapshot 180 Jun 17 22:14 list Together these snapshots take up about 209Gb which is fine, but creating metalink hashes takes a very long time. We don't serve these via mirrorbrain, so are these hashes actually needed? Just wondering out loud. The current metalink job has been running for nearly two days now. (maybe not so unusual given the server load). -- Per Jessen, Zürich (24.9°C) Member, openSUSE Heroes -- To unsubscribe, e-mail: heroes+unsubscribe(a)opensuse.org To contact the owner, e-mail: heroes+owner(a)opensuse.org

3 3