gyptazy
@gyptazy@gyptazy.ch
#FreeBSD jails final part, after this i may start with examples, something new with design, hope you like it.
Configuring everything automated I don’t care if it is native or NAT.
Not everyone can afford an own server, not everyone has the knowledge, not everyone has the time to maintain and (security)patch it. Next problem is, as soon as it gets to legal problematic content hosting an own solution might still get taken offline easily.
If the DMCA report is filled to Discord or to your server hoster who takes your whole server offline doesn't really matter.
You can find all #BSD & #Linux boxes right here:
https://gyptazy.ch/blog/collection-of-vagrant-boxes-images-for-apple-silicon-based-on-arm64/
#aarch64 #applesilicon #vm #virtualmachine #NobleNumbat #noble #numbat #Vagrant #DevOps #Canonical #Ubuntu #Linux #release #pipeline
But of course there're also people who want to abuse everything (within the first iteration last year
, BoxyBSD got abused for spamming). While spamming is just an easy thing to deal with, things can escalate quickly. That's why I need somehow an easy verification system that is not too annoying. If PayPal is no option (which I can fully understand), there could also be a fallback solution.
Within the signup process the same email address must be used and a dummy payment of 0,01USD be performed. Via the API I can get validate the email address. The idea is that all person verification have already been done by PayPal. Next, I'm not processing any financial data because PayPal has dedicated contracts with each user. But I need to get my point of view safe because I don't want to get sued for any mistakes or wrong assumptions I made by providing a valuable service for free for the community.
I really like this approach because of the data minimalism. It just needs a pubkey and the related user for authentication. No email, no password,… nothing. Doing this in a webinterface could also be possible but with much more efforts by creating client certificates from BoxyBSD CA.
But I’m still not quite sure if this will make it to prod
Having a look at the specs of the VF2 doesn’t solve the issue for me:
https://doc-en.rvspace.org/VisionFive2/Datasheet/VisionFive_2/power_consumption.html
So the standby is 4.1W in table 1 and full 9.3W in table 3.
But I think element 1 and 2 in table 3 are mixed? They’re the same except of a fan on top, but with fan lower consumption?
In my tests (https://gyptazy.ch/misc/collection-of-images-and-information-for-risc64-board-visionfive2/) I came always over 70° without active cooling. Running geekbench it consumed more than 13W.
Measured with a Refoss power plug. Even in idle I had more than 7W.
(measured without any device attached/plugged in, running from SD (no NVME attached), so basically no additional consumers).
#SecurityPatchManagement tools like #QualvoSec may help integrating automated security patches.
#infosec #linux #BSD #Debian #RockyLinux #CentOS #RedHat #FreeBSD #patchManagement #SecurityPatching #Patching
Currently, I only have only bandwidth & connection notifiers. Each VM is monitored for the network stats. I don't want to filter any traffic right now (like the initial BSDBoxy project, where people started to spam).
The initial idea of BoxyBSD is to provide a value especially to newcomers and people who can't afford things like this but should have a possibility to learn. Out of the Fediverse, e.g. on X (where I have my biggest follower base), many people are interested in such things but can't afford it. They're often from India or Africa. I don't want to generalize it here in any way, but bringing this up because of verification methods. While I could solve phone, sms or even postcard verification for more or less for free in Europe, everything out of Europe would take much time, more efforts and some money.
My next idea was a dummy payment by PayPal. PayPal accounts are well verified (unless they're overtaken and compromised). A dummy payment of 0,10 USD could do it. But I'm not quite sure if I want to deal with such data, even when not storing them and using them only for one-time verification. From a technical perspective this could be easily done with PayPal's API, but dealing with real names, addresses and financial data requires a different data policy and some other things. Honestly, I'm not even sure if this could be done on as "donation" base or if I have to deal with the tax office in that case.
TL;DR I need some time to get more details about that but currently I don't want to deal with any of these things and highly try to avoid getting sued for any mistakes I could potentially do when dealing with such things. And that's the sad point where things get complicated...
1. Write SSH server implementation without any usage (just accepting user auth on pw and pub-key)
2. Add API communication
3. Wrap some cli tools
My first implementation was done in around 30 minutes in Python but then I decided it would be cool to write it in Rust for more practice. That took me honestly hours...
If it's done I will provide the sources on GitHub. But we can also talk about the details in matrix, just ping me...
And the best #manpageblog is opensource, everyone can use it!
A: Using my 4x #RV64 #VisionFive2 boards - each board has 8GB. This could lead into a temporary and time limited, dedicated usage of 7-30d.
B: It could be shared across with 7 users by #jails on #FreeBSD. Requires better support in FreeBSD.
C: QEMU emulated instances running on amd64
I’d really like to see rv64 being pushed and it was excactly the reason to get those boards to get more experience on that platform. However, just sharing some ideas - it does not mean that they will be available in the near future (but would be cool if so).
You can now find some #smokeping graph on #BoxyBSD's status page: https://boxybsd.com/status/
Do you miss any destination? Let us know!
Any desired destinations missing? Let me know!
If you've lost it, have a look at this great project by @gyptazy :
BoxyBSD - Free FreeBSD Jail/VM Hosting
BoxyBSD just started!
#BoxyBSD is a non-profit VM & service provider for the open-source community with a focus on BSD based Systems like #FreeBSD, #OpenBSD and #NetBSD. BoxyBSD also provides additional services like webhosting, git, email and DNS solutions for #opensource projects to give valuable things back to the community.
You can find out more on https://boxybsd.com or in Matrix #BoxyBSD:bsd.cafe
oh no, oh no, oh no no no no no!
Honestly, (thats a personal feeling) the BSD community is much more about sharing and providing knowledge (especially in a very valuable form). We can see this in different approaches like @vermaden@bsd.network with his BSD focused newsletter, @stefano@bsd.cafe pushing in for this awesome
#BSDCafe community or @dexter@bsd.network pushing all the jails/bhyve stuff (and there are many more examples, sorry not to mention all ones!).
Everyone does it for free in a suitable way with his own resources each one can afford. Everyone is helping each other. Let’s see that we can bring more values into the community.
You already mentioned some of the interesting points like jails, which are still heavily used even nowadays. But also other things like zfs (ok you could also do it on Linux), pf, etc.. This service should give the possibility to test such things but also all other things which require a static IP - running own Mailserver (including ptr, …), authoritiive name sever,…
If it even helps just a single person to improve it was worth. Currently, everything is build on and running on my personal devlab systems where I can provide leftover resources, but still - for my own security reasons - they’re running on a different net link including completely different ip subnets (imagine getting hit by mail blacklist, etc.).
I know, it’s limited, because it’s running on my resources that I can provide for free to the community - it’s not much and we’re starting with just 50 free systems, but there’s hope to increase it by time. I also already got in touch with other ones that have similar ideas where we could boost this up.
But it also needs something like a self-service portal in long-term. However, for the website I stick to my self-written #manpageblog engine - I guess that fits pretty will here when it's only about serving #FreeBSD, #OpenBSD & #NetBSD.
This being said, I don't want to write a self-service portal for the web and thought about a #ssh service where you just login and can perform several actions like PTR, snapshots, system reset etc.
Currently, I only implemented the user management from an "admin" perspective. A sandbox style can be seen here:
ssh -p 2222 boxybsd@2001:470:54d7:1337::2
Password: create
It's a self-written sshd alike service which communicates with the API and some other bins. Die user login can be done by pub key and pw auth. Feel free to give it a try, it's a sandbox mode on a sandbox vm.
where I created the email:
support@manpageblog.boxbsd.bsd.hosting.gyptazy.ch
finally, I save money :)
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...
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.
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
Let’s see what will come next week…
Happy Easter!
#arm64 #aarch64 #vagrant #vagrantcloud #applesilicon #vm #vmware #fusion #bsdcafe #netbsd10
Last successful back: 6 years ago
Last run: Failed
just kidding... I'm not doing any backups at all.
Ok, ok, still kidding
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.
src: https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users
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.
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/
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.
CC: @ben@kwiecien.us
Not going into details, this should not result into flamewars. We should be happy, that we have to possibilities to choose.