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.)
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
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
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
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
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
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
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
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
Hi all,
Martin and me run the following command on "minnie" (the salt master):
> minnie (saltmaster):~ # salt '*' cmd.run 'sysctl net.ipv4.tcp_sack=0' --out=text >/root/tcp_sack-fix.txt
This is a mitigation for the latest vulnerabilities in the TCP stack of
Linux. Machines will still need to be updated and rebooted to properly
(and persistently) fix the issue.
Best regards,
Karol Babioch