NAS

I'm also interested in experience utilizing Intel N100 based NAS. My use case is for backup purposes with a similar raidz2 configuration. Let us all know how it goes!

Unless there is a past history of abuse why can't we simply edit a post at any time. I ran into this again today and it's really frustrating.

If I were to sum it up HexOS should operate under the principle that applications are not not be trustworthy and build out their infrastructure accordingly.

HexOS needs to establish a threat model with their curated applications and communicate that to the community. What kind of threats could we face based on how an application is being used and exposed to the network? Use Case 1: Exposing an Application to the WAN (Public Access) Threats: External Attackers: Malicious actors may exploit vulnerabilities in the application, potentially allowing unauthorized access. DDoS Attacks: Distributed Denial of Service attacks could overwhelm the application and its associated infrastructure. Man-in-the-Middle (MitM) Attacks: Attackers could intercept communications between users and the application. Misconfigured Security Measures: Vulnerabilities arising from misconfigured HexOS firewall rules or other security protocols could expose internal services. Use Case 2: Exposing Services Through LAN Only Threats: Internal Threats: Malicious users or compromised devices within the LAN pose risks to security. Exploitable Configurations: Poor application setups or vulnerabilities could be exploited by other trusted users or devices. Lateral Movement Risks: A compromised endpoint within the LAN could facilitate lateral movement to access other internal services. Challenges in Mitigation Some threats are difficult to mitigate effectively: DDoS Attacks: When executed well, these attacks are challenging to block and often require upstream infrastructure beyond HexOS to manage effectively. Firewall Configuration: While HexOS firewalls can be configured to improve security, managing upstream infrastructure, such as routers or dedicated firewalls, falls outside the scope of HexOS documentation. My Recommendations Users may need to expose certain applications only through the WAN (for external VPN access or public access) while limiting others to the LAN. It is crucial to recognize that the LAN should not be treated as a trusted network, as other services can be compromised, serving as a foothold for further intrusions. The following recommendations can help enhance security, depending on backend implementations designed to protect users: Application Isolation Deploy applications in separate virtual or physical environments (e.g., using containers or separate Virtual Private Clouds). Restrict outbound and inbound traffic to only the necessary connections for application functionality, applying the principle of least privilege. Access Control Implement strong authentication and authorization mechanisms (e.g., OAuth, API keys) to ensure that only legitimate users can access the system. Traffic Encryption Utilize HTTPS to encrypt data in transit, safeguarding against MitM attacks. Implement VPN gateways that can securely manage encrypted traffic for sensitive operations. Many of these thoughts mention here come from seeing some open source projects like casaos and cosmos-server that have mitigated some of these security threats. I'm sure Hex OS can provide even better experience if they lay the proper groundwork now. That ground work starts with the egress and structuring templates for applications.

I wouldn't mind throwing my hat into the beta test.

Clarification to the post above: restore in reverse chronological order one at a time. If that's true can we expect a average hexos to follow that practice? sigh fyi... the edit timeout needs to be removed from the forums.

I reached out to another forum for clarification about ZSF. So I understand now that a rollback is a rollback and not a restore. A rollback mounts that read-only snapshot allowing recovery of files. I believe my initial concern is still valid. A rollback is only helpful if the user knows explicitly what needs to be restored.even (if it is exposed by a file system) Two have (users A and B) 4000 in photos Immich User B has been tagging a thousand photos over the course of a weeks The application crashes and is unrecoverable. This goes unnoticed for two weeks. How does the A user know when to restore when there are many bad snapshots of application not working? Assume they don’t have a deep knowledge of application (looking at logs, most people don’t). It seems to me the user would have to use trial and error to with multiple restores of the application to discover it's working snapshot. However this comes at a great risk of losing data. In this case rollback isn’t helpful because the corrupt data isn’t obvious to the user. They don’t know if it application can run just by looking at files nor can they know how much of losing the metadata because it stored in a database. The only thing I can think of the user will have to restore incrementally in chronological order to ensure they get the latest working snapshot for the application without data a loss.

As I understand random nature of errors occurring with any type of RAM that ECC RAM mitigates. However it does ECC RAM maintain data integrity when the ECC RAM starts to go bad?

Oh, I'd be really nervous about that. At this point there should be really two drives a parody if there's and 8-wide pool. Most drives die during resilvering which of course one drive won't protect against.

Appreciate your time to respond and understand I did read your initially before posting. I tried to express these concerns based on how an average user would understand them but that's not helpful now. My overall confusion and frustration with ZFS is why I became HexOS customer. I didn't feel I could keep my data and especially applications safe with truenas when trying to juggle replication, snapshots and clones. ``` The zfs rollback command can be used to discard all changes made since a specific snapshot. The file system reverts to its state at the time the snapshot was taken. By default, the command cannot roll back to a snapshot other than the most recent snapshot. To roll back to an earlier snapshot, all intermediate snapshots must be destroyed. You can destroy earlier snapshots by specifying the -r option. If clones of any intermediate snapshots exist, the -R option must be specified to destroy the clones as well. The file system that you want to roll back must be unmounted and remounted, if it is currently mounted. If the file system cannot be unmounted, the rollback fails. The -f option forces the file system to be unmounted, if necessary. Clones can only be created from a snapshot. When a snapshot is cloned, an implicit dependency is created between the clone and snapshot. Even though the clone is created somewhere else in the dataset hierarchy, the original snapshot cannot be destroyed as long as the clone exists. The origin property exposes this dependency, and the zfs destroy command lists any such dependencies, if they exist. Clones do not inherit the properties of the dataset from which it was created. Use the zfs get and zfs set commands to view and change the properties of a cloned dataset. For more information about setting ZFS dataset properties, see Setting ZFS Properties. Because a clone initially shares all its disk space with the original snapshot, its used property is initially zero. As changes are made to the clone, it uses more space. The used property of the original snapshot does not consider the disk space consumed by the clone. ``` - Correct me if I'm wrong. When a restore occurs the intermediate references via cloned or snapshots must be destroyed? Snapshots or clones are considered an intermediate if the restore takes place earlier than the preceding references. - I like the idea of bringing a file system that simplified to the user to explore snapshots before they commit to restore. That's great! - However, visibility to the file system does not help when data is stored in a corrupt database/config of an application. The user's only choice is to simply to restore and see if the app works. Hopefully this shows more of my concern even if it comes out of the lack of fully understanding ZFS. if you say I'm wrong we've got this covered here at HexOS both from data and an application standpoint I will take your word for it.

I'm looking for a backup buddy 🙂 I would be very curious to know what HexOS recommends for the pool set up.

Why should be burdened moderators with such a task? Deleted posts can simply just be hidden but still visible if the user wants to investigate what was said just like the edit button.

Currently it seems the timeout within less than 10 minutes. Really it's kind of silly to have any sort of timeout.

Considering UI cloud-based does not function locally so reverse ssh tunnel out and a ssh tunnel is not for the target audience unless completely automated. They've said elsewhere that they're considering local UI support but it may be very limited. I hope hey maximize local functionality outside of the initial set setup.

It's also important to note that files, in the traditional sense, aren't the only thing that can be lost of value. Say if you finished tagging 1,000 photos in your collection through Immich. That's metadata in a database, which is not reflected through a file explorer.