Je ne suis pas certain que ça réponde à ta question, mais j’ai un Kimsufi qui a bien supporté la migration.
Sur un public cloud de base (S1-2 / 1vcore 2GB RAM) tout a parfaitement fonctionné.
Le seul problème c’est que l’interface d’OVH n’a pas “suivi” les mises à jour de mon serveur. Il considère donc que mon serveur tourne sous “Debian 8 - deprecated - 2017-12-05”.
J’ignore si c’est un gros problème ou non. J’avoue que j’ai un peu la flemme de faire une “clean install”…
1 Like
A mon avis, ce n’est pas du tout un soucis.
J’ai réalisé une migration de YNH 3 vers YNH4 dernièrement.
Aucun souci pour passer version release(vps cloud 20Go de base OVH)
L’une des choses en premier lieu effectué une backup de ton serveur puis upgrader ton kernel (toujours sous debian 9 , voir doc OVH)
Puis si cela fonctionne comme pour moi , il ne y aura aucun problème pour une dist-upgrade debian Buster.
PS: la migration de postgresql m a posé un petit souci mineur.
Au besoin voir cet article
Bonjour,
Je suis intéressé par les possibilités du Public Cloud de OVH de séparer des volumes en ajoutant des disques de stockages. Je pense utiliser un Public Cloud pour une association.
J’aurai des questions…
Admettons que je garde un volume assez conséquent pour la partition /home où se trouve aussi les données d’un Nextcloud,
Je pourrais rajouter un autre espace disque pour /var/mail assez conséquent pour les mails des utilisateurs aussi.
Ensuite, est-ce que je peux créer un espace disque isolé pour certaines applications qui seraient elles publiques (un service offert par l’association) pour par exemple Opensondage, et EtherCalc ??
ou bien seulement Cryptdrive que je découvre et qui me semble encore mieux ! superbe outil qui peut remplacer certaines apps lourdes de Nextcloud d’ailleurs…
Bonjour @rodinux ,
Oui, tout est possible ! Dis-toi qu’en gros chaque dossier présent dans ton Yunohost peut virtuellement être exporté sur un disque séparé. La question est simplement à quel niveau de détail tu souhaites aller, sachant que la plupart des applications sont en fait réparties dans plusieurs endroits sur le système. Nextcloud, par exemple, stocke par défaut toute la partie php dans /var/www/nextcloud, toute la partie base de données dans la base sql (je ne sais plus où c’est dans le système) et toutes les données dans /home/yunohost.app/nextcloud/data.
Les données ne sont jamais totalement séparées. J’ignore ton cas d’usage
→ est-ce pour séparer la facturation ou répartir les coûts ? Si oui, alors le mieux est de viser la partie “lourde” des applications (souvent /home/yunohost.app/tonApplication). Dans des cas comme Opensondage ou EtherCalc, le volume de données doit être tellement ridicule que je ne vois pas bien l’intéret de les séparer.
→ est-ce pour des raisons de sécurité ou vie privée ? Si oui, alors clairement il te faut deux Yunohost, ce qui est nettement plus clean et sûr (et pas beaucoup plus cher)
Je ne sais pas bien encore, mon idée est d’offrir un espace Nextcloud aux membres de l’association, donc en effet j’ai séparé la partition /home où se trouve aussi /home/yunohost.app/nextcloud/data.
Puis j’ai envie d’offir un service public, là je miserai bien sur Cryptpad, je galère un peu à bien le configurer pour l’instant, je découvre…
J’avais par exemple ajouter OnlyOffice à Nextcloud, mais si il y a Cryptpad à côté, je pense l’enlever de l’instance Nextcloud, du coup j’ajouterai un lien vers Cryptpad dans Nextcloud.
Du coup, ma question est, comment procéder pour allouer un espace sur un disque dur séparé à l’application Cryptpad,
Je me demande si le plus simple n’est pas de déplacer tout le fichier /var/www/cryptpad sur ce disque et de le monter ensuite dans le /etc/fstab ?
ou bien de créer un lien symbolique sur le dossier ?
Ou de jouer sur la config de l’application ??
Je vois ceci sur le dossier de config, mais il y aurait plusieurs dossiers à déplacer:
/* globals module */
/* DISCLAIMER:
There are two recommended methods of running a CryptPad instance:
1. Using a standalone nodejs server without HTTPS (suitable for local development)
2. Using NGINX to serve static assets and to handle HTTPS for API server's websocket traffic
We do not officially recommend or support Apache, Docker, Kubernetes, Traefik, or any other configuration.
Support requests for such setups should be directed to their authors.
If you're having difficulty difficulty configuring your instance
we suggest that you join the project's IRC/Matrix channel.
If you don't have any difficulty configuring your instance and you'd like to
support us for the work that went into making it pain-free we are quite happy
to accept donations via our opencollective page: https://opencollective.com/cryptpad
*/
module.exports = {
/* CryptPad is designed to serve its content over two domains.
* Account passwords and cryptographic content is handled on the 'main' domain,
* while the user interface is loaded on a 'sandbox' domain
* which can only access information which the main domain willingly shares.
*
* In the event of an XSS vulnerability in the UI (that's bad)
* this system prevents attackers from gaining access to your account (that's good).
*
* Most problems with new instances are related to this system blocking access
* because of incorrectly configured sandboxes. If you only see a white screen
* when you try to load CryptPad, this is probably the cause.
*
* PLEASE READ THE FOLLOWING COMMENTS CAREFULLY.
*
*/
/* httpUnsafeOrigin is the URL that clients will enter to load your instance.
* Any other URL that somehow points to your instance is supposed to be blocked.
* The default provided below assumes you are loading CryptPad from a server
* which is running on the same machine, using port 3000.
*
* In a production instance this should be available ONLY over HTTPS
* using the default port for HTTPS (443) ie. https://cryptpad.fr
* In such a case this should be also handled by NGINX, as documented in
* cryptpad/docs/example.nginx.conf (see the $main_domain variable)
*
* Note: you may provide multiple origins for the purpose of accessing
* a development instance via different URLs, like so:
* httpUnsafeOrigin: 'http://127.0.0.1:3000/ http://localhost:3000/',
*
* Such configuration is not recommended for production instances,
* as the development team does not actively test such configuration
* and it may have unintended consequences in practice.
*
*/
httpUnsafeOrigin: 'https://sousdomaine.domaine.tld',
/* httpSafeOrigin is the URL that is used for the 'sandbox' described above.
* If you're testing or developing with CryptPad on your local machine then
* it is appropriate to leave this blank. The default behaviour is to serve
* the main domain over port 3000 and to serve the content over port 3001.
*
* This is not appropriate in a production environment where invasive networks
* may filter traffic going over abnormal ports.
* To correctly configure your production instance you must provide a URL
* with a different domain (a subdomain is sufficient).
* It will be used to load the UI in our 'sandbox' system.
*
* This value corresponds to the $sandbox_domain variable
* in the example nginx file.
*
* CUSTOMIZE AND UNCOMMENT THIS FOR PRODUCTION INSTALLATIONS.
*/
// httpSafeOrigin: "https://some-other-domain.xyz",
/* httpAddress specifies the address on which the nodejs server
* should be accessible. By default it will listen on 127.0.0.1
* (IPv4 localhost on most systems). If you want it to listen on
* all addresses, including IPv6, set this to '::'.
*
*/
httpAddress: '::',
/* httpPort specifies on which port the nodejs server should listen.
* By default it will serve content over port 3000, which is suitable
* for both local development and for use with the provided nginx example,
* which will proxy websocket traffic to your node server.
*
*/
httpPort: 3000,
/* httpSafePort allows you to specify an alternative port from which
* the node process should serve sandboxed assets. The default value is
* that of your httpPort + 1. You probably don't need to change this.
*
*/
httpSafePort: 3001,
/* CryptPad will launch a child process for every core available
* in order to perform CPU-intensive tasks in parallel.
* Some host environments may have a very large number of cores available
* or you may want to limit how much computing power CryptPad can take.
* If so, set 'maxWorkers' to a positive integer.
*/
// maxWorkers: 4,
/* =====================
* Admin
* ===================== */
/*
* CryptPad contains an administration panel. Its access is restricted to specific
* users using the following list.
* To give access to the admin panel to a user account, just add their public signing
* key, which can be found on the settings page for registered users.
* Entries should be strings separated by a comma.
*/
adminKeys: [
"[user@sousdomaine.dimaine.tld/XXXXXXXXXXXXXXXXXXXXXxxXXxXXxx=]",
],
/* CryptPad's administration panel includes a "support" tab
* wherein administrators with a secret key can view messages
* sent from users via the encrypted forms on the /support/ page
*
* To enable this functionality:
* run `node ./scripts/generate-admin-keys.js`
* save the public key in your config in the value below
* add the private key via the admin panel
* and back it up in a secure manner
*
*/
supportMailboxPublicKey: '',
/* CryptPad will display a point of contact for your instance on its contact page
* (/contact.html) if you provide it below.
*/
adminEmail: 'user@domaine.tld',
/* We're very proud that CryptPad is available to the public as free software!
* We do, however, still need to pay our bills as we develop the platform.
*
* By default CryptPad will prompt users to consider donating to
* our OpenCollective campaign. We publish the state of our finances periodically
* so you can decide for yourself whether our expenses are reasonable.
*
* You can disable any solicitations for donations by setting 'removeDonateButton' to true,
* but we'd appreciate it if you didn't!
*/
removeDonateButton: true,
/*
* By default, CryptPad contacts one of our servers once a day.
* This check-in will also send some very basic information about your instance including its
* version and the adminEmail so we can reach you if we are aware of a serious problem.
* We will never sell it or send you marketing mail.
*
* If you want to block this check-in and remain set 'blockDailyCheck' to true.
*/
blockDailyCheck: true,
/* =====================
* STORAGE
* ===================== */
/* Pads that are not 'pinned' by any registered user can be set to expire
* after a configurable number of days of inactivity (default 90 days).
* The value can be changed or set to false to remove expiration.
* Expired pads can then be removed using a cron job calling the
* `evict-inactive.js` script with node
*
* defaults to 90 days if nothing is provided
*/
//inactiveTime: 90, // days
/* CryptPad archives some data instead of deleting it outright.
* This archived data still takes up space and so you'll probably still want to
* remove these files after a brief period.
*
* cryptpad/scripts/evict-inactive.js is intended to be run daily
* from a crontab or similar scheduling service.
*
* The intent with this feature is to provide a safety net in case of accidental
* deletion. Set this value to the number of days you'd like to retain
* archived data before it's removed permanently.
*
* defaults to 15 days if nothing is provided
*/
//archiveRetentionTime: 15,
/* It's possible to configure your instance to remove data
* stored on behalf of inactive accounts. Set 'accountRetentionTime'
* to the number of days an account can remain idle before its
* documents and other account data is removed.
*
* Leave this value commented out to preserve all data stored
* by user accounts regardless of inactivity.
*/
//accountRetentionTime: 365,
/* Starting with CryptPad 3.23.0, the server automatically runs
* the script responsible for removing inactive data according to
* your configured definition of inactivity. Set this value to `true`
* if you prefer not to remove inactive data, or if you prefer to
* do so manually using `scripts/evict-inactive.js`.
*/
//disableIntegratedEviction: true,
/* Max Upload Size (bytes)
* this sets the maximum size of any one file uploaded to the server.
* anything larger than this size will be rejected
* defaults to 20MB if no value is provided
*/
//maxUploadSize: 20 * 1024 * 1024,
/* Users with premium accounts (those with a plan included in their customLimit)
* can benefit from an increased upload size limit. By default they are restricted to the same
* upload size as any other registered user.
*
*/
//premiumUploadSize: 100 * 1024 * 1024,
/* =====================
* DATABASE VOLUMES
* ===================== */
/*
* CryptPad stores each document in an individual file on your hard drive.
* Specify a directory where files should be stored.
* It will be created automatically if it does not already exist.
*/
filePath: './datastore/',
/* CryptPad offers the ability to archive data for a configurable period
* before deleting it, allowing a means of recovering data in the event
* that it was deleted accidentally.
*
* To set the location of this archive directory to a custom value, change
* the path below:
*/
archivePath: './data/archive',
/* CryptPad allows logged in users to request that particular documents be
* stored by the server indefinitely. This is called 'pinning'.
* Pin requests are stored in a pin-store. The location of this store is
* defined here.
*/
pinPath: './data/pins',
/* if you would like the list of scheduled tasks to be stored in
a custom location, change the path below:
*/
taskPath: './data/tasks',
/* if you would like users' authenticated blocks to be stored in
a custom location, change the path below:
*/
blockPath: './block',
/* CryptPad allows logged in users to upload encrypted files. Files/blobs
* are stored in a 'blob-store'. Set its location here.
*/
blobPath: './blob',
/* CryptPad stores incomplete blobs in a 'staging' area until they are
* fully uploaded. Set its location here.
*/
blobStagingPath: './data/blobstage',
decreePath: './data/decrees',
/* CryptPad supports logging events directly to the disk in a 'logs' directory
* Set its location here, or set it to false (or nothing) if you'd rather not log
*/
logPath: './data/logs',
/* =====================
* Debugging
* ===================== */
/* CryptPad can log activity to stdout
* This may be useful for debugging
*/
logToStdout: false,
/* CryptPad can be configured to log more or less
* the various settings are listed below by order of importance
*
* silly, verbose, debug, feedback, info, warn, error
*
* Choose the least important level of logging you wish to see.
* For example, a 'silly' logLevel will display everything,
* while 'info' will display 'info', 'warn', and 'error' logs
*
* This will affect both logging to the console and the disk.
*/
logLevel: 'info',
/* clients can use the /settings/ app to opt out of usage feedback
* which informs the server of things like how much each app is being
* used, and whether certain clientside features are supported by
* the client's browser. The intent is to provide feedback to the admin
* such that the service can be improved. Enable this with `true`
* and ignore feedback with `false` or by commenting the attribute
*
* You will need to set your logLevel to include 'feedback'. Set this
* to false if you'd like to exclude feedback from your logs.
*/
logFeedback: false,
/* CryptPad supports verbose logging
* (false by default)
*/
verbose: false,
/* Surplus information:
*
* 'installMethod' is included in server telemetry to voluntarily
* indicate how many instances are using unofficial installation methods
* such as Docker.
*
*/
installMethod: 'unspecified',
};
Ici j’imagine que je devrai déplacer les dossiers: /var/www/cryptpad/datastore/ et /var/www/cryptpad/data/ et /var/www/cryptpad/block/ et /var/www/cryptpad/blob/, mais c’est hasardeux, sachant que tout cela est chiffré…
Qu’en pensez-vous ?? je devrais détacher ces questions sur un autre topic peu-être ?
Tu peux suivre la doc OVH « ajouter un disque externe VPS » ou quelque chose s’approchant. L’idée est de configurer ton disque, de le monter temporairement dans /mnt/disk, de faire un mv de tout le dossier que tu souhaites délocaliser (par exemple /var/www/cryptpad/*). Ensuite au moyen de fstab tu montes le disque en pointant sur /var/www/cryptpad et le tour est joué !
1 Like
Cette doc pas encore fusionnée peut aider: [enh] Improve documentation about multi disk setup by zamentur · Pull Request #1698 · YunoHost/doc · GitHub