Adding Zoph, a photo organizer, to FreedomBox

Development
1

I am Debian packager for Zoph, and have just made a Freedombox module for it, currently at https://salsa.debian.org/jlines/freedombox/-/tree/zoph

My plan is to update upstream packaging for apache configuration to test for Freedombox authentication include and use that. I also want to rename the created admin user to the Freedombox user who is currently logged in, and I am not sure at the moment how to find this. Logging in to zoph as admin and creating the user within zoph gets single signon,

I have a bit of tidying to do, but quite a lot of the module - heavily based on Roundcube one, is done.

6 Likes
2

Hello, integrating Zoph sounds really great!

Don’t fully understand what you intend, though, would every freedombox user be a Zoph admin for their own photos, and allow guest access etc. to others?

3

For a first instance the Freedombox admin user who installs the package will become a zoph administrator. Zoph authentication is done via Freedombox, but zoph rights are managed via its own system. Sharing of individual photos is done by sending a link which is unique to that photo, so does not require the recipient to have an account. Sharing via the link only gives access to the photo, and not the information such as the people in it.

Putting it behind Freedombox authentication means that zoph guest access will not be possible. Note that zoph is aimed at being a Photo Organiser, rather than a gallery, and I see that main use as being people with thousands of photos, who want to be able to manage them. I am hoping people with big photo collections who currently share them though Dropbox, Google Drive, Facebook, Flickr etc will find a Freedombox an easier way to manage their photos, and then find that they can do other things on it too.

2 Likes
4

@johnlines, I am excited to know that you are working on bringing Zoph to FreedomBox. Thank you! I did a basic review of the code so far and it looks good.

One way the initial admin account can be setup as follows:

  • Set the password for the pre-existing ‘admin’ user to a large random value.
  • Take the name of the user currently installing the app with Django’s request.user and pass it on to the setup action (current implementation with first LDAP user seems a bit hackish). Use that to create a user account with Zoph.
    • If the name is admin, do nothing.
    • If the name is something else, then create a new Zoph user with that name, set password to a large random value and make this user account an admin (by setting user_class = 0).
  • Preferably, show the name of the admin user in the interface. Query this from Zoph’s CLI/DB and show it in the interface.
  • Explain how user management works in the description.

For regular user accounts, it is less than ideal to have to create the user with the same name as FreedomBox user in Zoph. Zoph should automatically create missing user accounts from the REMOTE_USER header when it encounters this for the first time. This is common with apps using third party authentication. However, the current behavior will be okay until we fix this in the upstream code. The upstream author seems to indicate that doing would be okay and that it only requires some further work.

For guest usage, I believe, we might be able to do something with the FreedomBox + Apache configuration. User visiting the app will do so as anonymous user and only when login operation is triggered will see redirection to FreedomBox’s single sign-on. When visiting as guest, the Apache configuration can set REMOTE_USER to empty (or a particular value) and Zoph can interpret that as Anonymous user (there seem to a setting for which user account to use for anonymous users). I am not entirely sure if this possible but we can try.

If you are stuck somewhere please do let me know, I would love to assist.

5

I am very new to django - thanks for the hint about request.user, that looks a much better route. I was creating the user directly with a Mysql command, but I found that creating the user that way does not set up their preferences, so, I have put in an issue https://gitlab.com/jeroenrnl/zoph/-/issues/142 to ask for this as a capability in the CLI, which will make user creation more future proof.

I will look at picking up the request.user and passing it into the action code, even if it will not be fully ready just yet.

If upstream is happy to create zoph accounts from the REMOTE_USER header that would be simplify user creation

I am not sure if guest usage, from an anonymous user is worth setting up, There is potentially quite a lot of personal information in the zoph database, and management could quickly become a nightmare. I did create a wedding_guest user to share our wedding photos, and circulated the password for that to specific people, and that only had access to the Wedding Album, but as access only went to people I trust it was not the same as making it public.

No user is needed to access a photo which is shared by sending a link as each link only gives access to one photo, and that is how we share most of our pictures.

Have just committed a first pass at a user manual.

One of the things I want to do soon is a way to change where the photos are stored. On my own zoph system I can link /var/lib/zoph to a larger disk, but this will want something better to be usable by ‘real’ people.

6

If you have any Django difficulties, I can help out. I guess we can skip the guest access for now.

The user manual is written at https://wiki.debian.org/FreedomBox and automatically downloaded into the source repository before a release. This allows for a wider set of contributors including translators to work on the manual. Please transfer the contents of the raw.wiki file to wiki.debian.org. Also go ahead and create a merge request with a ‘Draft’ or a ‘WIP’ tag: folks can give review comments better.

7

Yes, I think it’s something very important, to introduce a good scheme to store all the apps’ user data, so that it is always sorted and accessible in the same way, easily understandable, and trivial to work with.

Wish there were more responses to the idea or questions to improve this:

8

Some help with the django bits would help, I suspect the app will need to create forms and views at some point anyway, I have put in a WIP: tagged merge and will look at adding Zoph.raw to the Debian Wiki

9

A good flexible file manager to decide where the photos should be stored would be very useful, although the other features you are discussing are less relevant to the Zoph case. All imported photos live in a single directory tree, and are all owned by the Zoph user, though they can be tagged on import or later, with characteristics like the photographer. The photographer may well not have an account on the Freedombox at all, for example my wedding album has photos taken by the official photographer, and by family and friends.

I do know people who have external disks on their network, which look to them like Windows Shares and being able to put photos on them, or mount them from Freedombox to read photos off them would be very useful

10

What should a file manager have to be useful to the Zoph app? Freedombox has a directory selection form that apps can use, see for example the Transmission app. The form lists also shares enabled in the Samba app.

11

It’s also not quite clear to me why Zoph would require the user to configure it with a filemanager (or a directory selection form).

As you write the files are stored and owned by the zoph user, do I get it right that zoph itself is running as a central instance, not running as separate instances for different freedombox users?

I would see the filemanager as a tool for the freedombox users to directly access their data directories, any general files and the ones from all their apps.

With a central Zoph instance, I’d see the admin to be able to use the filemanager or samba to access the Zoph files directly. Other users would only have and use the Zoph web access. The photos could by default, for example, be stored in /home/admin/private/zoph and be owned by the user admin, facilitating easy direct access. If the app actually runs as yet a separate user for security reasons, that user could get access to its particular admin’s directory though ACLs.

Correspondingly, if multiple freedombox users could have their own Zoph instance, their photos could by default be saved in /home/<user>/private/zoph, for example (or more generally /home/<user>/private/photos?). Simple to access and manage without requiring the user or admin to first take care to configure such location and permission things properly in some unknown, and hard to support, custom way.

Mounting /home or parts of it from an external disk could still be possible without changing the directory layout. By configuring mount points for external disks as drafted in the issue.

12

Making photo storage explicit is mostly a matter of scale. If you are running your Freedombox on a typical setup as in https://wiki.debian.org/FreedomBox/Hardware then /var/lib/zoph - the default storage location on a Debian system, will be on something like a 16Gb or 32Gb SD card. My digital camera has a 32Gb SD card,
If someone is a photographer rather than a system administrator, they will not want to run out of space to upload photos to almost as soon as they start, particularly if they have added an extra disk just for this purpose. If they had been persuaded by a friend (who might be a system administrator, but probably working at a distance) to try a Freedombox as an alternative to "various options (Amazon, Google pics, Flickr etc" then it is worth anticipating problems before they reach them.

There is no advantage to the admin being able to access zoph photos directly - they can, but the whole point about zoph is the database. If you have many thousands of photos, and you want to find pictures, say of castles in Northumbria then the database is the key.

I appreciate what you are looking do in the user collaboration area, but zoph has its own user who owns (from a file system point of view) all of the photos.

13

A file selector, like the one for the transmission app is needed before the Zoph app goes live.

An improvement to the selection form, for Zoph purposes, would be an indication of available disk space in selected locations.

14

Yes, let’s do that, your friend’s server scenario does also match the intention of my proposals nicely. (Should be nicely covered, let me try to explain.)

Let’s consider that freedombox should be a good basis to organize photos (i.e. Zoph), but also much more. There are many apps, most need storage space (and for example with redundancy possibly). So it’s good not to only look for a Zoph solution, because having a more general solution has many more benefits.

With a couple of apps, Zoph being an example, the main data access may clearly not happen through direct file access. Nevertheless following the same conventions for data storage still allows them to play well with other apps, out of the box, for example with backup or sync apps, or your favorite contributed helper script. And all this without requiring every admin to sort out and configure a local solution, and possibly having to support many different custom solutions.

So, bulk storage is needed by multiple apps, and I’d rather not want to have to configure this for every app, and friend’s home server, separately. That would bring unnecessary problems.

As the default filesystem with freedombox is BTRFS, one solution is attaching additional disk(s) and to move the whole system over while running. (Recommended for sdcard based systems.)

With a central data storage convention for freedombox, one can also simply add an external storage (filesystem) and have it mounted. For example even at its base (/home according to the proposal), and thus have all data (and configration) now residing on the (large) external disk. (Perfect for a fast SSD system with large storage disks.)

Note that additional disks (space or redundancy) may be added to the root- or home-filesystem as desired (with the default btrfs), completely independent from the /home directory conventions. The files would always be at the same predictable directory locations on every freedombox, regardless of the underlying disks, filesystem, network protocol, etc.

With freedombox (plinth) showing the free space of the filesystems (possibly warning if running low or running on sdcard), and plinth allowing to manage the disks, there should be no need for users to ever having to solve app specific file/directory selection problems.

(And I have left out the collaboration permission, network access, and backup and syncing possibilities (and left all those solved problems aside). But I think they are also truly practical for freedombox to really completely work out of the box, and mostly all based on following the useful and flexible multi-user /home storage conventions.)

15

Thank you, I had not appreciated how powerful brtfs can be. As I understand from that discussion it would be possible to leave photo storage pointing at /var/lib/zoph, as is the default location, and expand the total storage available to the system, via BTRFS.

If the additional storage was a NAS device mounted over SMB, for example, it might still be useful to use it for bulk storage.
At present my priorities are to de-kludge the creation of the zoph account for the first user, making some proper icons, fitting in with the current backup/restore system, and possibly making it a more explicit question at install time as to whether the user wants OpenSteetMap mapping support enabled.

I think these are ambitious enough for my first venture into the Freedombox/Django environment.

16

You’re very much welcome. Just wanted to explain what I’d see as unnecessary efforts (per app dir selection).

Um, yes, I’d guess that with central user-data external NAS directories could also get (bind)mounted somewhere in the /home tree, just like external disks.

17

I think so, yes. And one more thought, that’s not only due to BTRFS. Also, just symlinking from the default debian package locations to a central freedombox user-data storage location could be a well working solution for existing users and scripts as well as the freedombox development.

18

The zoph branch is almost working, but has a niggle in that ‘Launch Web Client’ is enabled as soon as installations is done, but it is not configured properly until ‘Setup Zoph - status is not set up’’ has been clicked.

The zoph admin user is renamed to the Freedombox user who installed Zoph, and single signon works

I would appreciate it if someone who understands the django framework better could have a look at what needs to be done to sort that part of the installation.

1 Like
19

The zoph branch now does not enable ‘Launch Web Client’ until the App is configured. Adding another user within Zoph with a username matching a Freedombox username works, enabling Zoph usage for that user as well.
Their permissions within Zoph are controlled via the Zoph Admin interface, for access to Albums, ability to upload etc.

1 Like
20

Is there a mode, or some way, to use zoph with an existing photo collection that is already organized, and should continue to be organized in sub-directories?

Ideally, with options to continue managing the directories and the photos in them with zoph. Zoph only adding online features (and exif data) to the collection.

(As for example “photoview” and “pigallery2”.)

Think newly taken photos getting uploaded by syncthing into an incoming folder, and then sorting them into subfolders and adding database entries with zoph.

1 Like