gyptazy
@gyptazy@gyptazy.ch
Some may remember #BoyBSD which got heavily abused during the beta test. Now, I'm trying it again with longterm VMs. Currently, I grant only VMs to very active user accounts that are providing valuable content to the community (in the hope they're not abusing the service, especially not in a bad way). However, this feels unfair, especially I want to target people that cannot afford VMs to learn and practice on #FreeBSD, #NetBSD and #OpenBSD - especially when it requires a static IP for name server etc.
Currently, I have no clue except of processing financial data like SEPA, PayPal etc. to have at least a minimum of safety. I thought about GPG, by signings - but I guess GPG is not really used by newer dev- & sysops.
I'm hosting this services for free, with my personal efforts and hardware. I do it to bring some help and valuable things back to the community and especially to newcomers in this field but I don't want to deal everytime with ddos, email spamming, torrent or tor exit nodes. While this is still annoying, there're still some other things you really don't want to deal with. So, I need a useful safety net for me.
@gyptazy Could you, for example, restrict outbound connections? I think that's what sdf.org does for free accounts, though I'm not sure of the implementation details.
Currently I only see:
* Providing dummy fee by CC, SEPA or PayPal (or a small onetime setup fee). But dealing with money means to have much more data safety in place. I do not want to have knowledge or any thing else of banking data etc. Next, it could lead into issues with tax offices.
* No joke: Sending a real letter to the residence address of a user (which just takes too long, overhead and money from my site to send a letter)
I already use dedicated networks for this service to be at least safe from blacklist etc. for my personal systems. It's really a pity...
> I think my biggest fear is to deal with illegal content provided on these systems.
If you possibly purge the VM after say X amount of time, I think that could be a good limitation. Just to make sure, mention this (no illegal materials) in the terms of conditions. It's shouldn't a big problem, as you'll not going to host them, but all will be done under the user action and will be removed under X amount of days. I also think, if it's possible to limit somehow the network activity, it could be a nice thing. (e.g. some can try to "host" these things for sharing...) so that's a hard thing to deal...
I personally think, you should give trust to users, as we can't determine whether someone has good or bad intention. There are possibly chances that good people may go away..and there are also possibly chances that more bad ones come there. It's 50% for each...
@gyptazy thanks for this approach! Unfortunately I believe this is... really difficult.
Sharing some technical details about how I'm setting up the hosted email service. It will not be a service of BSD Cafe but tied to my own business. It will run entirely on BSD systems and on bare metal, NOT on "cloud" VPS. It will use FreeBSD jails or OpenBSD or NetBSD VMs (but on bhyve, on a leased server - I do not want user data to be stored on disks managed by others). The services (opensmtpd and rspamd, dovecot, redis, mysql, etc.) will run on separate jails/VMs, so compromising one service will NOT put the others at risk. Emails will be stored on encrypted ZFS datasets - so all emails are encrypted at rest - and only dovecot will have access to the mail datasets. I'm also considering the possibility of encrypting individual emails with the user's login password - but I still have to thoroughly test this. The setup will be fully redundant (double mx for SMTP, a domain for external IMAP access that will be managed through smart DNS - which will distribute the connections on the DNS side and, in case of a server down, will stop resolving its IP, sending all the connections to the other. Obviously, everything will be accessible in both ipv4 and ipv6 and in two different European countries, on two different providers. Synchronization will occur through dovecot's native sync (extremely stable and tested). All technical choices will be clearly explained - the goal of this service is to provide maximum transparency to users on how things will be handled.
#BSD #FreeBSD #OpenBSD #NetBSD #emailHosting #encryption #ZFS #dovecot #opensmtpd #rspamd #emailSecurity #techTransparency #ipv6 #Europe
@stefano sounds nice!
@stefano i cant wait to read about the details.
@marzlberger thank you! I'm actively working on it.
@stefano how you you want to store the user credentials?
@marzlberger I'll be using mysql (two instances, master/master replicated). Credentials will be stored there, password will be encrypted, of course.
Welcome back my friends to the show that never ends, I'm so glad you could attend come inside come inside.
The multi-day outage of bsd.network is over and we have returned!
In short, there was an administrative mixup of our account with the hosting provider, and we got disconnected. Then, because our account is not a normal account in their system, it took far far longer to get sorted out than it ordinarily would.
But we're back on the Fediverse, toots are a-flowin, and we're ready to get back to regular life.
@phessler Thansk so much for all your hard work, great to be back :).
(Anything to do with accounts like this is always super painful >.<)
@phessler Tell us the truth, you went down on Friday and came back on Sunday. All this reminds me of something. Jokes aside, welcome back!
@phessler Welcome to Cloud Computing!
I've moved my account over here to bsd.cafe.
@tehpeh Welcome!
@stefano thank you for maintaining such a great service!
@tehpeh of <https://forums.freebsd.org/threads/geli-zfs-vs-zfs-native-encryption-performance.90970/> fame!
GELI+ZFS vs ZFS native encryption performance
As a reminder how Apple prefers their own services: There is no apparent way to autoconfigure e-mail settings on an Apple device, unless you're domain is in some Apple settings database or hosted by some big cloud provider.
No service records, no autodisover endpoint. Apparently nothing will 'just work'.
Still sticking with Apple anyway, hopefully EU regulations will fix this sooner or later.
But if you are selfhosting mail for your family or group, there are a lot of details to fill in on every device you want to use.
Am I missing something here? Any tips greatly appreciated.
@gyptazy I found the configuration profile option, but this is way more work in installing and updating for both the engineer/hoster and all the individual end users. This is just making things more complicated than they need to be. More work, more clicks, more questions.
But thanks for your remark nonetheless!
Let’s see what will come next week…
@gyptazy at least it's a 4-day week which should reduce the amount of garbage by 20%.
@gyptazy bsd.network seems back now live
@gyptazy I always liked bsd.cafe, maybe because I like coffee ☕
@gyptazy he's an exemplar of community leadership
@gyptazy @stefano I have now a KISS failover solution, using only tools available in the OpenBSD base system! https://foo.zone/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.html
Happy Easter!
#arm64 #aarch64 #vagrant #vagrantcloud #applesilicon #vm #vmware #fusion #bsdcafe #netbsd10
@gyptazy wow, that was fast. Thank you!
Today is a good day to do your backups.
Last successful back: 6 years ago
Last run: Failed
just kidding... I'm not doing any backups at all.
Ok, ok, still kidding
@gyptazy If an unmonitored service fails in a forest, does it make a sound
And if you are curious about the #xz #compromise, a little update on the #Debian site:
As already written, the archive processing is currently off (nothing new coming to testing/unstable/experimental, no mirror updates pushed out).
Automated build daemons for the affected architectures have been stopped, and only two of them regenerated with a clean #stable environment. They are building for the security archive only, nothing else, right now. That part is safe.
Members of the Release, FTP, Security, Build-Daemon and Sysadmin team are discussing what the next steps are. There are multiple different ways that can be taken, with different drawbacks and amounts of work involved.
Also, it is not yet fully known what the malicious code all could do, so there might be much more that needs to be done later - or not. Unknown as of now, needs the analysis of it to finish, which is not easy nor fast.
Regarding the xz backdoor: "The attackers made a serious strategic mistake: they made #PostgreSQL slightly slower." https://www.postgresql.org/message-id/CA+hUKGK4ZewHeVtnbBc_pbZRHZa6GyO=UpJ5XDmomA9Lf0xpkA@mail.gmail.com
@mbanck how dare they?
Does anyone know what happened to bsd.network?
for nginx:
location = /favicon.ico {for apache:
alias /var/www/mysite/img/favicon.ico;
}
RewriteRule ^/favicon\.ico$ /var/www/mysite/img/favicon.ico
src: https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users
@stefano reference commit: https://github.com/tukaani-project/xz/commit/cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0
Jia is second largest contributor in xz utils and yea... let's not imagine that they didn't add something else in there.
I don't think their SSH (and GPG) keys were compromised, as just 4 days ago they did removed the security part (e.g. how to properly report).
Commit: https://github.com/tukaani-project/xz/commit/af071ef7702debef4f1d324616a0137a5001c14c
This very much remind me about color.js ...
PostgreSQL maintainer Simon Riggs has died in a small airplane crash, on Tuesday.
For those who didn't know Simon, he's responsible for PostgreSQL Binary Replication and many big data features. He and I worked together at Greenplum 2006-2008. Postgres would not be the world-leading DB it is today if it weren't for him.
@fuzzychef as a pilot, I am profoundly sad about what happened. We know that things can happen and we train as much as we can for those moments. The truth is that we will be never fully ready.
Thanks for sharing such a lovely story, it's a nice way to remember him. 🥹
I have installed #OpenBSD on a tiny VPS: https://extrowerk.com/2024-02-29/Tiny-OpenBSD-VPS.html
@gyptazy Nice! No, i dont use matrix. Maybe in nect life or something.
Well, F***.
Sorry, that's the only thing that came to mind. Thank Cthulhu, I am not hosted with them.
@ParadeGrotesque
F +1
I’ve just created two VPS there to setup my new project… Because they offered network features not available else where… :-/
@gyptazy ASN and floating IP to be used as a CARP config.
@robonuggie I'm not sure it is the case here, but Vladimir did "disappear" on previous occasions. What I'm trying to say is that maybe Vladimir is just dealing with some problems or doing an offline thing like he did before. I sure hope that's the case, as he's really great guy! Unfortunately, I don't have any contact of his so I can't confirm that. If I do find out something more, I'll let you know.
@meka Maybe it is for the same reason, and if it is, then he will no doubt be gone for a longer period..... thanks
Here you find more information about it and how to install/use it.
https://gyptazy.ch/blog/proxmox-new-import-wizard-for-migrating-vmware-esxi-virtual-machines/
@gyptazy Whilst I welcome Proxmox into Enterprises and I hope that they will increase their subscriptions sell, I hope also that it doesn't go down the "enshittification" path.
Is so tempting/easy for a vendor to fall in that space.
@gyptazy @romanzolotarev let me have a look. There should be a form somewhere. Might be CSP headers. Thanx for catching that.
Me: These Apple M2 MacBooks are amazingly fast, everything is almost instantaneous.
Apple:
@gyptazy Compare and contrast with Chrome OS, where the update happens transparently in the background, and the reboot is just as fast as a regular reboot. Apple could do it if they cared.
@gyptazy and working like a charm <3
Proxmox VE: new Import Wizard available for migrating VMware ESXi based Virtual Machines https://forum.proxmox.com/threads/new-import-wizard-available-for-migrating-vmware-esxi-based-virtual-machines.144023/
Ipv6-only life: no discord, no telegram, (no archive.org tho), only fedi and email
@yottatsa Uh, AFAIK, Telegram works on IPv6 only. Are you assigning IPv4 even if you are not routing them?
@gyptazy welp, usually don’t wanna reply to these kind of statements.. 1) there’s he.net tunnelbroker + pppoe + native vodafone PD, so i’m unfucking it up as i go; 2) not a network engineer, remembering policy-based routing stuff as go; 3) no nat64, so no way in hell v4-only would work for now
telegram is working tho for the sake of convo
@mast:~$ uptime
17:29:05 up 499 days, 18:00, 3 users, load average: 1.51, 0.86, 0.86
6 hours to go, and Emacs.ch has reached peak uptime of 500 days! 🎉
@gyptazy We use Ubuntu Live Kernel patching and run Glitch edition, which is updated on a bi-weekly basis.
Being too long absent in this topic feels like starting from scratch again…
Now, I’m running a friendly beta test within the #BSD Community (primary #BSDCafe & BSD fans) for free small sized hosted #VMs / #Jails (IPv6 only).
The first system is already full. Let’s see how this will be (ab)used?! Maybe, the next stack will start after Easter.
@gyptazy great news!
@gyptazy I can only recommend Debian in this situation
@gyptazy systemd is the way
Not going into details, this should not result into flamewars. We should be happy, that we have to possibilities to choose.
CC: @ben@kwiecien.us
Sure, technically everything works fine on operating systems like #FreeBSD, #OpenBSD, #Debian, #Fedora etc. and all my monitoring, backup and admin infrastructure is #IPv6 only for years. But dealing with clients is something different. I think most clients already support #DualStack, especially within my circle but it could still be annoying for people that are forced to use #IPv4 only.
@gyptazy ran into this yesterday:
@jhx Stable an illusion? I run BSD at my $dayJorb because it is so gorram stable.
@gyptazy 152 logical cores?
2x Epyc 7473X 24 cores (48 threads)
1x Epyc 7453 28 cores (56 threads)
Please don’t ask any questions why different cpus were used 😉
@gyptazy that's some big powerful machine
@gyptazy OK, but what if you decide that next week you only need 512GiB of RAM because it's going to be really slow with most of the world on leave?
But the week after, you need to go back up to 1.72TiB again?
Meanwhile next week, there's another server on which you intend to run some really resource-heavy maintenance tasks, so you want to allocate some of the RAM you remove from the first server to the one you want to run maintenance on?
@gyptazy Thats what they say... lol. That's a small allocation of servers assuming v32 cores, but worth it if your use case supports it. Scaling and cost management is where cloud makes its ground floor debut for infrastructure buying decisions.
🔐 Linux 6.9 Adds New RISC-V Vector-Accelerated Crypto Routines - Phoronix
「 RISC-V with Linux 6.9 implements support for more vector-accelerated crypto routines. Among the work is RISC-V vector accelerated AES-{ECB,CBC,CTR,XTS}, ChaCha20, GHASH, SHA-256, SHA-384, SHA-512, SM3, and SM4 algorithms 」
I need to process more than 8TB of photos and additional TBs of videos…
So, sure - let's go! You'll find it here (currently uploading):
https://app.vagrantup.com/gyptazy/boxes/casaos0.4.7-debian12-arm64
- #Debian 12 #AnsibleSemaphore
- #FreeBSD 14 #snac (#ActivityPub / #Fediverse)
- #Debian 12 #Nextcloud 28 (#nginx / #mysql)
What do you want next?
#AppleSilicon #virtualization #aarch64
https://gyptazy.ch/blog/collection-of-vagrant-boxes-images-for-apple-silicon-based-on-arm64/
The series of articles on the quest for one's digital freedom continues: Make your own E-Mail server - Part 2 - Adding Webmail and More with Nextcloud
https://it-notes.dragas.net/2024/03/21/make-your-own-email-server-freebsd-adding-nextcloud-part2/
@patrizia
Linux still doesn't have an actual jail feature. Or CTRL-T. Or faster networking. Or a ZFS-compatible license.
But GNU/Linux is 20% slower with ZFS and 100GbE networking.
There's a reason they're leaving, but I have no idea what it is.
@trashheap
[*] At least for now. It's a bit of a chickenIndeed, it's exactly this one! When it comes to me, I run my own fediverse instance but I still enjoy X much more than the Fediverse. All the interaction, integration and UI related things are nicer and more usable for me. Dealing with different clients, different functionalities, different UIs is a pain - I love it streamlined.
and egg situation, isn't it? Content creators
won't come here because we don't have
two billion users. And uses won't join en
masse because their favourite content
creators are still on TikTok and Instagram.
But why am I here? This question can be answered easily - because of the content with much value! Especially when someone is deeply into tech, you find great people providing awesome content with much value. That's also what I try to do here - provide some valuable content. But I guess this is more a thing for people living the opensource way (and we are honestly a niche).
QualvoSec is supposed to be very minimalistic and only to keep the systems up to date on the latest patches given in a used repository. In theory, you could already do this with the whitelist mechanism and defining the package version (https://github.com/gyptazy/QualvoSec/blob/main/src/server/patch.yaml#L20-L21), but in that case you need a utility to include all the packages (sure, you could do this by hand but you probably don't want to do this).
1. This leads us to the first solution. It could be done by the admin tool and generate the patch manifest. Current packages can be requested from the client if the http server is activated (optional, up to everyone to use it).
2. A solution could also lead into freezing the repositories itself but only works when having own repositories (e.g. with aptly, repomgr, etc.). This is independent of QualvoSec.
3. Don't integrate similar solutions
I can clearly see the reasons and needs for patch freezing (especially when having the typical ends for dev, stage and prod). I'm happy to hear more feedback and I will have a look into such an implementation. Thanks!
"If you’re a new creator and you’ve been trying to grow your #TikTok platform, don’t!"
Imho, if you want to contribute, like in opensource and bring in value for the community - yes you're right. But if you want to make money, TikTok & Co is probably the better way.
Just my 2 cheap cents...
My internal papers:
https://cdn.gyptazy.ch/tech-talks/QualvoSec_Security_Patch_Management/QualvoSec_A_Security_Patch_Management_Tool.html
Nothing: | 7 |
<10$: | 7 |
<20$: | 12 |
<50$: | 12 |
>50$: | 20 |
Endkiller solution: Just keep your phone home (which might be difficult nowadays)
I had similar ideas only for vacation, but having flight plan, credit card etc. on it already killed that idea. But the watch was able to also solve this.
For me, it's just going out with my watch on my wrist. Still able to communicate by email, iMessage, sms and to answer phone calls. But that's not all - I can still track my sport activities, pay by nfc, open the door at home, open the car etc. What I could do - but isn't fun at all - write on matrix, X, Fediverse. I could, but I also deactivated all notifications. Social media is only pull - I do it when I have time, instead of push and getting anything of a pressure or similar.
The dir is browsable and contains all ones:
https://cdn.gyptazy.ch/files/docs/freebsd/jails/
I cannot say this too often - not only from a team leading perspective, but also from a good friend one!
I joined in freshly, they taught me - I taught them! Together we improved day by day! Almost 10 yrs later, the team is still the same - no one left. I think I can say that everyone enjoys the work and everyone is doing a really great job! I really love this team and it works out that well because we're:
honouring, understanding, trusting & respecting each other!
This is not only about "happy posting" etc. - it's more about also getting taught. It does not automatically mean that a teamlead is always right. It does not mean that this person is always choosing the right path. And it is really good and important that everyone can take the opportunity without any fear to talk about any concerns. This should always be taken seriously, no one can know everything and no one is always right! What did I say in my first sentence - they taught me! And yes, this was the first thing what happened. They taught me!
But what is my hope? I had two really (and I mean it this way) good mentors. I hope, I can be the same for other ones. Helping to improve, to become better... But everyone is special in its own way and needs to treated that way. Hopefully, I can find the right directions...
@padukajorat@mastodon.social (all credits to him!) released his FreeBSD Jails - Part IV sheet! This series of slides is perfectly to explain jails to new users!
The PDF (and all other parts) are hosted here:
https://cdn.gyptazy.ch/files/docs/freebsd/jails/FreeBSD_Jails_Part_4.pdf
Got one very cheap at netcup.de
Keep in mind: You should always have an additional monitoring node out of your own infrastructure!
@gyptazy @alpinelinux there is no bhyve on OpenBSD. Never tried FreeBSD except for OpnSense. Also I guess I am used to my favourite stack KVM with libvirt.
One of it also runs a production tor node (https://gyptazy.ch/misc/running-a-riscv-based-production-tor-relay-node/) and another one this Fediverse instance :)
But sure, KVM does its job great. :)
But I can also fully understand and see the needs of everyone else running Linux - so I created the related Linux images and collection for RV.
#amd64 offers the best support and is fast.
#arm64 is very efficient and also very fast.
#riscv is amazing & exciting (but slow with my current hw, but I can deal with it)
While amd64 & ARM64 work perfectly fine with #FreeBSD, the #RISCV hardware support (beside #qemu stuff) is still very limited. Currently, #Ubuntu and #OpenBSD work very well there.
#QualvoSec's upcoming features:
- whitelist (packages to update only)
- blacklist (package to refuse from being upgraded)
- API (list of installed packages & versions on nodes)
- Multiple patch windows
- Grouping
- First iteration of (the still very limited) admin tool
#patchmanagement #security #infosec #debian #freebsd #rockylinux #redhat #ubuntu #BSD #securitypatchmanagement #Fedora