Change Details

**Jail** Recreate the jail in WindRiver would be the ideal, with a private IP for access. Previous names were //[[ https://devcentral.nasqueron.org/phame/post/view/5/tronstad_2014-11_changelog/ | Tronstad ]]// (T167) and //Theyk//. Previously, it was a Debian GNU/kFreeBSD experiment. It can be a regular FreeBSD jail instead, as Debian GNU/kFreeBSD isn't currently an active interest. **ZFS dataset** Files should be stored on /datacube/ftp (create a ZFS volume), mounted too in the jail devfs must be mounted in the jail to have access to ZFS datasets outside **SFTP access** Anonymous FTP access could be replaced by SFTP public access. Create an `ftp-public` account with a rotating, known password, or a rotating, known SSH key published, or some service with form to accept any key. With proper monitoring of uploaded files, it's OK. The main risk is to be used as a warez dump, but they bruteforce search for FTP public sites, and historically started by put a text file, and... that's it because if you delete it soon enough, they know it's not a stable storage to use. With SFTP special manipulation, it requires specifically targeted attack instead of bruteforce usual one. **FTPS access** No current use case. There is a good support from library, but if it's only to download, we expose a HTTPS mirror with an even better support. **Files content** A Google search on "ftp.nasqueron.org" shows there is no specific content to restore, as none is still referenced. In the past, some FreeBSD ports used it. **References** - https://forums.freebsd.org/threads/how-to-create-a-zfs-dataset-within-a-jail.62198/ - https://forums.freebsd.org/threads/setting-up-sftp-only-accounts.20049/

**Jail** Recreate the jail in WindRiver would be the ideal, with a private IP for access. Previous names were //[[ https://devcentral.nasqueron.org/phame/post/view/5/tronstad_2014-11_changelog/ | Tronstad ]]// (T167) and //Theyk//. Previously, it was a Debian GNU/kFreeBSD experiment. It can be a regular FreeBSD jail instead, as Debian GNU/kFreeBSD isn't currently an active interest. **ZFS dataset** Files should be stored on /datacube/ftp (create a ZFS volume), mounted too in the jail devfs must be mounted in the jail to have access to ZFS datasets outside **SFTP access** Anonymous FTP access could be replaced by SFTP public access. Create an `ftp-public` account with a rotating, known password, or a rotating, known SSH key published, or some service with form to accept any public key. With proper monitoring of uploaded files, it's OK. The main risk is to be used as a warez dump, but they bruteforce search for FTP public sites, and historically started by put a text file, and... that's it because if you delete it soon enough, they know it's not a stable storage to use. With SFTP special manipulation, it requires specifically targeted attack instead of bruteforce usual one. **FTPS access** No current use case. There is a good support from library, but if it's only to download, we expose a HTTPS mirror with an even better support. **Files content** A Google search on "ftp.nasqueron.org" shows there is no specific content to restore, as none is still referenced. In the past, some FreeBSD ports used it. **References** - https://forums.freebsd.org/threads/how-to-create-a-zfs-dataset-within-a-jail.62198/ - https://forums.freebsd.org/threads/setting-up-sftp-only-accounts.20049/

**Jail** Recreate the jail in WindRiver would be the ideal, with a private IP for access. Previous names were //[[ https://devcentral.nasqueron.org/phame/post/view/5/tronstad_2014-11_changelog/ | Tronstad ]]// (T167) and //Theyk//. Previously, it was a Debian GNU/kFreeBSD experiment. It can be a regular FreeBSD jail instead, as Debian GNU/kFreeBSD isn't currently an active interest. **ZFS dataset** Files should be stored on /datacube/ftp (create a ZFS volume), mounted too in the jail devfs must be mounted in the jail to have access to ZFS datasets outside **SFTP access** Anonymous FTP access could be replaced by SFTP public access. Create an `ftp-public` account with a rotating, known password, or a rotating, known SSH key published, or some service with form to accept any public key. With proper monitoring of uploaded files, it's OK. The main risk is to be used as a warez dump, but they bruteforce search for FTP public sites, and historically started by put a text file, and... that's it because if you delete it soon enough, they know it's not a stable storage to use. With SFTP special manipulation, it requires specifically targeted attack instead of bruteforce usual one. **FTPS access** No current use case. There is a good support from library, but if it's only to download, we expose a HTTPS mirror with an even better support. **Files content** A Google search on "ftp.nasqueron.org" shows there is no specific content to restore, as none is still referenced. In the past, some FreeBSD ports used it. **References** - https://forums.freebsd.org/threads/how-to-create-a-zfs-dataset-within-a-jail.62198/ - https://forums.freebsd.org/threads/setting-up-sftp-only-accounts.20049/