This would require the main proxy running as root or with some other sort of elevated privileges to allow cross-user network access though, right? If so, wouldn’t that essentially make the user-specific reverse proxy unnecessary in most cases?

I think this is what OP was originally trying, but this approach breaks when each service’s Podman service runs on its own localhost user.

I didn’t see the logs when I originally posted. However, I’m not sure what the logs indicate. It could be that nginx successfully received the request and received an authorization error from Podman’s networking stack then returned a 503 error to the client (or logged the 503 response that was returned to nginx).

I’m not trying to convince you of this solution (I personally don’t like it), but I am curious what didn’t work for you. Were you unable to get the reverse proxy to serve each service? Were you unable to have the services behind the reverse proxy to talk to each other?

This is due to a security design deicison of Podman. Each user’s network(s) is only available to that user. This is great for most services, but can cause issues for some services - especially reverse proxies. Unfortunately, I’m not aware of an ideal solution. The only solution I’ve seen is moving the reverse proxy to another host and exposing the services’ ports on the localhost. I hope someone can provide a better solution!

I generally agree with this. Unless OpenAI has a track record of being poor stewards of open source projects, then right now the concern is mostly FUD.

However, this is a bit aggressive. It is appropriate to be skeptical about the intent of a controversial company acquiring another company that made a few popular open source projects or of the future state of those open source projects.

Just because a popular open source project is well liked today doesn’t mean the community will be happy with the project in the future or even that the project will forever remain open source. Some notable recent examples include Redis, Terraform, and CentOS.

I’m not too sure - I’m not too familiar with any of these services (including PinePods 😂). I know this type of feature is a common request for any audio related services though. I imagine that this is something that could be added at some point, but I’m not sure what the effort would be.

I don’t see anything about it on the roadmap for v1 or anywhere else on Pinepods’ issues. Perhaps the developer/maintainer @madeofpendletonwool@lemmy.world can chime in or an issue on Github can be created with more information about this feature request?

The biggest benefits are likely:

• Single service for all your podcasting needs (ie: searching, storing, playing, tracking, and syncing podcasts + listening history)
• Multi-device, cross-platform support (I know this can be somewhat accomplished through the process that you mentioned, but you would need separate apps for iOS and desktop/web)
• (speculation/assumption) It may be easier to get newer features added to Pinepods (especially those that you or the community contributes and/or for server-related features) since the project is focused on just podcasts
• I’m not aware of a similar all-in-one podcast server + client service. As Pinepods matures, it can offer features/services that may not be easily included in the services you mentioned. For example, searching by transcript across all downloaded podcasts or summarizing/combining multiple podcasts (which may be helpful if you listen to multiple daily/weekly/monthly “news” podcasts of a similar topic).
• Supporting a newer project and open source community

The first two may not apply to you in particular, but I’m sure if you have other users that use the services you support then I’m sure they would appreciate having to learn/use a single app/interface for podcasts instead of having to learn one for searching/downloading (if they care about that at all), one for listening on mobile, one for listening on web, and another for managing their download/play sync.

Lots of good suggestions in this thread! A few additional ones that I don’t think I’ve seen yet:

• Testing/QA server (eg: test existing software’s major upgrades before upgrading your “production” environment, test new services without impacting your “production” environment, test new operating systems/virtualization software/etc.)
• Learn automation (eg: Terraform, Opentofu, Ansible, etc.) or horizontal scaling (eg: Docker Swarm, Kubernetes, etc.) to try improving future upgrades and/or high availability
• Media center PCs (eg: Kodi, LibreElec, OSMC, etc.) or gaming PCs for various TVs around your house to replace Apple TVs/Google TVs/etc. or gaming consoles
• Home Assistant

Thanks for the response!

Sorry to hear about the frustrations regarsing F-Droid, but glad to hear it will at least be on IzzyOnDroid. Excited to check it out once it’s available on there!

Excited to see the app develop over time. I bet Pinepods will be able to meet all my podcasting needs sooner than I can imagine.

Thanks for the update! Really appreciate all of the work that has gone into this.

A few quick questions:

• Will the Android app be available on F-Droid? It looks like it should/will be, but I don’t see it on F-Droid at the moment.
• Is it possible to download episodes from a Pinepods server to a local device via a Pinepods client so the episodes can be stored on something externally, like a USB drive or old MP3 player? If so, can all/multiple episodes on the server for a podcast be downloaded without having to manually select each episode? The only download options that I have seen are for the server to download the episodes from the podcast’s source.

I believe Google plans to use Google Play Services to block side loaded apps. By default, GrapheneOS does not come with Google Play Services installed. I am not sure how things would work if the sandboxes version of Google Play Services that GrapheneOS provides is installed.

The issue about maintaining/updating GrapheneOS is a separate issue from side loading apps. That was due to Google shifting the development of Android to a closed source model and only open sourcing the final code. This limits the Grapheme team’s ability to anticipate changes and make any required adjustments until after the release of Android.

I think that any guides you find for Gitea + Renovate should work still for Forgejo + Renovate.

I believe the process is:

• Create Forgejo instance
• Create a user for Renovate within Forgejo
• Using the CLI on your local machine (or another tool to complete this step), create an SSH public/private key for the Renovate user
• Log into Forgejo using the Renovate user and configure the previously created SSH keys and separately generate a Forgejo token
• Create a Renovate instance with settings for at least RENOVATE_GIT_PRIVATE_KEY (SSH private key value), RENOVATE_TOKEN (Forgejo token value), RENOVATE_PLATFORM (gitea), RENOVATE_ENDPOINT (Forgejo API base URL), and any other Renovate settings that you may find helpful/necessary to configure (eg: GITHUB_COM_TOKEN, RENOVATE_AUTODISCOVER, etc.)
• Depending on how you want things to work, you may need to give the Renovate Forgejo user access to individual repos

It is not clear that this is the app that will be used for the new watches. I imagine it will support the new RePebble watches, but I believe that app was intended for the original Pebble watches.

The thing that makes it so unclear to me is that this is a repo owned by the Rebble team, not the RePebble team. I do not know how much overlap there is between the two teams, but the RePebble team does not have any open source repos that I could find. Any mention of open source software by RePebble (including the OS) are links to repos owned by other teams, which is a little concerning.

I understand that the watch operating system is open source. However, it seems that the watch will connect to a companion smartphone app. Do you know if the app is a requirement and/or if the app will be open source?

If you know your VPN’s DNS server, you can change your local DNS so that it redirects your specified domains/subdomains to the appropriate, local IP address and all other requests would then use your VPN’s DNS.

If you don’t know your VPN provider’s DNS server information, you may be able to still do something similar to the above depending on your setup. Otherwise, you could run your own DNS resolver or use a different DNS provider. I guess doing so could potentially be used to further fingerprint you, but the concern about “DNS fingerprinting” is moreso DNS leaks where your DNS queries are accessible to unintended parties due to improper configuration.

I believe the only other option would be to change your hosts file on each device you want to use to connect to your services, which is probably not the best approach and may be challenging/impossible for certain devices.

Also, unless you setup the self signed certs to be trusted on a network/domain level (or again on each individual device), you will likely get a warning/error about the self signed certs when accessing your services. You may need to work through this process each time the certs renew.

I recommend buying a domain if you do not already have one and finding a service that provides wildcard certification challenges. This would allow you to setup a valid, trusted certificate that you could reuse for all of your services. The only thing that you would need to provide is an email address (can be any email address) and your domain name (in addition to other information that may be required to setup an account at the cert provider, but you may already have an account there as it could be the domain name registrar or other services like VPS providers, Cloudflare, etc.). Since it is a wildcard cert, each subdomain does not need to be set publicly and if you only use the domain within your network, the domain does not need to be publicly associated with any IP address.

If you do go forward with that approach, you could use the wildcard cert directly within NginxProxyManager or other reverse proxies. They will also automatically update/maintain the cert for you.

I think there may be an issue where F-Droid is not properly recognizing the 64-bit version of Findroid. Maybe Droid-ify and/or the version of Android you are using won’t allow 32-bit apps to be installed.

Just to clarify - this is just an update that (I believe) is only available on IzzyOnDroid’s F-Droid Repo, which previously had prior Findroid versions available. This new v0.15.0 is not available on the main F-Droid Repo.

Is anyone only able to download the 32-bit version of this app via F-Droid? It looks like a 64-bit version has been made available starting with v0.3.0 and is also available on this new version.

Yes, I am using PersistentVolumes. I have played around with different tools that have backup/snapshot abilities, but I haven’t seen a way to integrate that functionality with a CD tool. I’m sure if I spent enough time working through things, I may be able to put together something that allows the CD tool to take a snapshot. However, I think that having it handle rollbacks would be a bit too much for me to handle without assistance.

Thanks for the reply! I am currently looking to do this for a Kubernetes cluster running various services to more reliably (and frequently) perform upgrades with automated rollbacks when necessary. At some point in the future, it may include services I am developing, but at the moment that is not the intended use case.

I am not currently familiar enough with the CI/CD pipeline (currently Renovatebot and ArgoCD) to reliably accomplish automated rollbacks, but I believe I can get everything working with the exception of rolling back a data backup (especially for upgrades that contain backwards incompatible database changes). In terms of storage, I am open to using various selfhosted services/platforms even if it means drastically changing the setup (eg - moving from TrueNAS to Longhorn, moving from Ceph to Proxmox, etc.) if it means I can accomplish this without a noticeable performance degradation to any of the services.

I understand that it can be challenging (or maybe impossible) to reliably generate backups while the services are running. I also understand that the best way to do this for databases would be to stop the service and perform a database dump. However, I’m not too concerned with losing <10 seconds of data (or however long the backup jobs take) if the backups can be performed in a way that does not result in corrupted data. Realistically, the most common use cases for the rollbacks would be invalid Kubernetes resources/application configuration as a result of the upgrade or the removal/change of a feature that I depend on.