On 07/05/2024 02.24, Tomás Leite de Castro wrote:
> Hi,
>
> I’m operating some mirrors in Lisbon, Portugal and I would like to add openSUSE to the list of public mirrors available at this server.
> I don’t know if my previous email got somehow lost.
> Mirror URL https://mirror.leitecastro.com/opensuse
> It’s available via rsync, http(s) and ipv4 and ipv6 enabled.
> This mirror is connected at 20Gbps and with a generous 8TB NVMe cache. No traffic, or geo limitations.
>
> Please let me know if you require any additional information,
I now added your mirror
https://download.opensuse.org/app/server/mirror.leitecastro.com
It seems to be only the second mirror in PT after ftp.rnl.tecnico.ulisboa.pt
You can sync repos from
rsync://stage-main-repos.opensuse.org/
and for what is not on there (e.g. debug, ports, repositories), use the
slower
rsync://stage.opensuse.org/
The mirrors mailing list is for notifying mirror operators.
Rather admin(a)opensuse.org is the way to get a mirror added.
Ciao
Bernhard M.
Hello,
here are the minutes of today's meeting:
Attendees: Christian, Doug, Jim, Georg
Status reports:
- no update on GDPR, added clarification to Wiki
- Doug provided update on bugzilla regarding communication needs from
SUSE IT
- Weblate being migrated to SaaS -
https://status.opensuse.org/#scheduled-43
-> prefer to keep i18n.o.o redirect
- monitoring/alerting for HAProxy and zypper (update/reboot status),
nginx/httpd in progress
- known_hosts repository + SSHFP records for all machines (generated
using a script upon creation of new VMs)
- repaired media upload in Matrix
- work on NetBox
- work on Mailman search index issue
- SUSE IAM UCS replacement: https://progress.opensuse.org/issues/159798
- SUSE helping with new debuginfod setup
Issues:
- multiple users reporting sporadic issues with cdn.o.o
* for example https://progress.opensuse.org/issues/159108
Regards,
Christian Boltz
--
Trusting a claim within the email itself that it's virus-free is kind of
like trusting a politician who goes on TV and says, "I am not a crook."
[Jay Hennigan in mailop]
Hello!
We are implementing changes to the Heroes OpenVPN.
There are three changes - two are already implemented, and you likely
did not notice - the other is breaking and requires changes in your
client configuration after the 12th of April (one week from now)!
SHORT version:
On April 12th, please visit the Admin Wiki and update your OpenVPN
client configuration with the latest examples:
Native OpenVPN:
https://progress.opensuse.org/projects/opensuse-admin-wiki/wiki/VPN#OpenVPN…
NetworkManager:
https://progress.opensuse.org/projects/opensuse-admin-wiki/wiki/VPN#Network…
Afterwards, delete any files containing Heroes credentials in plain text.
VERBOSE version:
1. BREAKING: Removal of compression
On April 5th, LZO compression will be disabled on the OpenVPN server.
If you want to connect on or after this day, you will have to remove the
respective option from your OpenVPN client configuration:
With native OpenVPN:
```
comp-lzo
```
With NetworkManager:
```
compress=lzo
```
If you do not remove this option after it has been disabled on the
server, you will receive error messages like "Bad LZO decompression
header byte: xxx" blocking you from working in the Heroes network!
This change is implemented due to inherent security issues with
compression in OpenVPN:
https://community.openvpn.net/openvpn/wiki/Compression.
2. Non-breaking: Removal of user/password authentication and change of
ciphers
Previously we used two layers of authentication for OpenVPN:
- LDAP username/password
- client certificates
The LDAP layer is removed as it often encourages users to store
sensitive data (i.e. the same passphrase also used for sudo elevation to
root on our systems!) in plain text and does not yield a security
benefit given the existing use of client certificates.
Additionally, we adjust the ciphers to make use of hardware acceleration
and to decrease CPU load as well as latency for users in remote
locations far away from our data center.
These changes have already been implemented and are compatible with
existing clients - however we still ask you to remove the following
lines from your client configuration:
With native OpenVPN:
```
auth-user-pass.*
cipher AES-256-CBC
data-ciphers AES-256-CBC
```
With NetworkManager:
```
username=.*
password-flags=.*
cipher=AES-256-CBC
[vpn-secrets]
password=.*
```
Make sure to also delete any files containing the plain text
credentials, such as the file previously passed as an argument to
"auth-user-pass".
You can already implement the changes mentioned in point 2 now, or you
do it together with the mandatory change mentioned in point 1 on April 12th.
All these changes are tracked and explained in
https://progress.opensuse.org/issues/151492.
Thanks for collaborating!
If you have any questions, please let me know.
Georg
Hi everyone,
for additional security, we disable DSA and RSA host keys on all
infra.opensuse.org machines in favor of Ed25519 and ECDSA. If you use a
modern operating system, you likely do not notice this change, and you
likely already trust either one of the more modern keys for the machines
you work with.
To ensure the authenticity of your SSH connections, I recommend only
connecting to hosts the keys of which you verified. I started a
repository containing an automatically generated known_hosts file with
trusted entries for all of our Salt managed machines - you can
incorporate this into your own known_hosts file.
It is now also possible to use DNS based verification using SSHFP
records, which are automatically generated for all machines - whilst
this is preferred over maintaining known_hosts entries, it requires
additional considerations in your client side setup.
The generated known_hosts file as well as instructions for utilizing the
SSHFP records can be found in this repository (from within the Heroes VPN):
https://gitlab.infra.opensuse.org/infra/ssh_known_hosts
Note the thor.infra.opensuse.org jump servers are already configured for
strict host key checking and DNS verification.
Best,
Georg
Hi!
I found about 760G worth of log file backups from back when Pontifex
still connected to backup.i.o.o.
I assume you don't need it, but since it's a lot of data I rather ask -
can I delete it? :-)
Cheers,
Georg
Hi,
as we are slowly fading out FreeIPA I renamed the
"ca-certificates-freeipa-opensuse" package to "ca-certificates-opensuse".
The new package obsoletes the old one, meaning if you have the
openSUSE:infrastructure repository installed on a machine, you will see
the replacement happen automatically during your next up/dup.
Whilst at it, I also pushed the package to a new dedicated project,
openSUSE:infrastructure:CA [1], in addition to openSUSE:infrastructure.
This might be useful if you want to keep the root certificate up to date
without keeping our big repository on your workstation.
Note that no source/certificate files were changed.
Cheers,
Georg
[1] https://build.opensuse.org/project/show/openSUSE:infrastructure:CA
Hello,
minutes of today's meeting (from
https://etherpad.opensuse.org/p/heroes202404):
2024-04-04 Heroes meeting
Participants: Doug, Georg, Jim, Knurpht, cboltz, Bill, Neal
- discussion about GDPR, Doug requesting clarification on process from SUSE
- example explanation for users about OneTrust (see Etherpad)
post-meeting additions by Georg:
- FreeIPA -> Kanidm migration, all clients moved over (GitLab +
Grafana switched from LDAP to oauth2, shell clients switched from sssd
to kanidm-unixd), account management for now still possible through the
FreeIPA GUI
- Database backups repaired (DC-migration leftover; PostgreSQL
backups to backup.i.o.o, MySQL to mybackup.i.o.o)
Best,
Georg
Hello,
the next Heroes meeting will be on Thursday (2024-04-04) at 18:00 UTC /
20:00 CEST in https://meet.opensuse.org/heroes
Note: Europe switched to summer time, which means the UTC time is now
18:00.
Besides our usual topics, Doug wants to discuss GDPR topics.
Feel free to add more topics to
https://progress.opensuse.org/issues/156874
Note: I have another event that evening, and will probably have to leave
early.
Regards,
Christian Boltz
--
He was the same guy formatting his linux two year ago because his
soundcard didn't work. After a while of consolehacking, google-ing and
investigating he setup windows again (it would be the better solution
... lmao). After windows was setup the soundcard didn't work again and
he plugged in the cable. [Philippe Vogel in suse-security]