Skip to first unread message
leonardo...@gmail.com
Jul 27, 2020, 2:03:20 PM7/27/20
to AtoM Users
Dan Gillean
Jul 27, 2020, 5:47:51 PM7/27/20
to ICA-AtoM Users
Hi Leonardo,
I will try to answer your questions more generally below. Please note that for many questions like this, the answer is often "it depends". As in, it depends on how you deploy AtoM, what resources (memory, disk space, CPU, etc) you allocate for it, and even the type of data you create (some operations can be quite resource intensive for records with many relations - either hierarchical like a large collection with many descendants, or relational like an authority record with many relationships to other authorities, descriptions, and terms).
- How much Database can you have?
At present, AtoM uses only one database. There may be ways to scale horizontally across several databases, but we at Artefactual have not explored this, and it may require development to support it fully.
- Number of users that can interact in the application?
There is no hardcoded limit on the number of users you can have. We have not tested this at scale to determine a limit on the number of concurrent users a system can have - this is one of those answers where "it depends". You will likely run into issues if you have many users trying to edit the same data (e.g. the same description, same hierarchy, etc), as AtoM database transactions will lock some records when being performed, but otherwise I would expect you can likely have a lot of concurrent users - though performance will depend in part on the specifications of the server.
- Database flexibility?
Can you tell me more about what you mean by this?
I will say that in 2.6, we have upgraded AtoM to use MySQL8. There are known issues using MariaDB because of this, since MariaDB does not yet officially support MySQL8, and the collation formats expected in v8 are not available, so AtoM fails when running the upgrade task.
Early on, we tried to abstract all database interactions in AtoM's code, using Symfony's Propel ORM. However, Propel 1.x has proven to be slow and unreliable at points - this is one of the reasons we want to fully replace AtoM's backend in the long-term, and remove Symfony and Propel. To work around these limitations in the meantime, there are some places where we have used raw SQL to bypass the ORM and optimize AtoM's performance. One unfortunate side effect of this is that the code is less abstracted now - you will need to use a database that uses MySQL's SQL syntax. We use the community fork Percona regularly without issues, but I'm not sure of others.
- How secure is the system?
A fair amount of security will depend on your deployment - there are more steps you can take to harden Nginx (or whatever webserver you are using) than what we cover in the docs, as just one example. Making sure your production site uses HTTPS/TLS will also increase security - services like LetsEncrypt will provide free TLS certificates if you don't want to buy one from a domain provider.
You can also use a two-site deployment as a way of increasing security - one internal read/write site for staff, which can be kept behind a firewall, or only be accessible via VPN, or have HTTP authentication or other protections applied. The other is configured as read-only (a setting that can be configured via a config file) public facing site. You can then use a replication script to pass data between the two when you want to update the public site. For more information, see:
That said, AtoM has undergone audits and penetration tests from some of our large national and international clients, and when needed, these clients have sponsored security fixes and enhancements over the years. There are always further improvements that could be made, and we have further plans for the 2.7 release, but overall, AtoM does well on enterprise-level security tests, and if your deployment is secure, then you should be fine.
Finally, note that AtoM does have some further security options in the settings as well, that can be used to further harden your site:
Be careful however! If you don't know what you are enabling, you could lock yourself out of the system! For example, if you enable the "Require SSL" setting, but you don't actually have a TLS certificate in place, then you won't be able to log back in - and you'll need to use SQL to change the setting in the database via the command-line. Same with the IP restrictions, if you enter an IP restriction that is not your IP!
Cheers,
he / him
--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/266f1536-9621-46a0-8d21-b2b51494731eo%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages