UpLoad Server: Difference between revisions

From Sea of Fate
Jump to navigationJump to search
Line 1: Line 1:
==Introduction==
==Introduction==


We need a method of easily getting image files uploaded from both LAN and Internet ready to be edited and displayed on the '''[[Webservers]]'''. For most of the webservers there will not be too many images to be uploaded so direct access with a FTPS server on the webserver host will be good enough. However, for the '''[[Plum (Photo)]]''' there will be a significant amount of images to be uploaded, it is after all the Piwgo photo webserver and some pre processing and backups will be needed. We expect to do the backups from
We need a method of easily getting image files uploaded from both LAN and Internet ready to be edited and displayed on the '''[[Webservers]]'''. For most of the webservers there will not be too many images to be uploaded so direct access with a FTPS server on the webserver host will be good enough. However, for the '''[[Plum (Photo)]]''' there will be a significant amount of images to be uploaded, it is after all the Piwgo photo webserver and some pre processing and backups will be needed. We expect to do the backups from '''[[Backup Server]]'''. There will be some changes to the backup server/plum webserver to reverse the storage we will have to change the documentation for them as well.
 
==Photo Management ==
 
The general idea is to have an upload server as a staging point to get rid of duplicates, organise metatags and maybe enhance some of the photos and eventually transfer to the Piwigo website on '''[[Plum (Photo)]]''', we will separate these duties on to this server. To make it all a self contained object we will make this a desktop Unbuntu install rather than the usual server installs. It is uncertain if that is going to be fast enough to actually edit photos but it should be good enough to edit any metatags.
 
===Workflow Outline===
 
The first thing to do is to dump all photos on the physical desktop PC on the 4tb drive it doesn't matter if there are duplicates as they will be addressed as part of this workflow. The important thing is to make sure there are none missing. Once there are photos to upload simply copy them to Satsuma via the SMB shares Import Export, they have been mapped to a pair of network drives (S: is Import and T: is Export). These network shares are on SMB so will only ever work on the LAN and they have been blocked from the internet. The photos are on Satsuma dir /mnt/images/Import and /mnt/images/Export. Once the files are on Satsuma they will be checked for duplicates and previously known, all new unique files will be moved to a separate input directory for processing by Digikam. When there are a few photos the user can login to the plum desktop and start Digikam (I was going to use Shotwell but it would appear that Digikam is a better fit). Digikam should pull the photos an copy them in to its own directory. The user edits the photos or adds tags to them and when finished they should be exported to another staging area to be sent to '''[[Plum (Photo)]]'''. While this leaves us with several copies of the same photos we should be able to have a script periodically delete the various copies, as a long term feature the photos will be left on the Digikam working directory (it is likely that Digikam will show loads of errors if it's working directory is cleared). The running of the various scripts will be tracked with some XML log files to cope with errors. The main processes flow will be tracked by a full database on Mandarin the [[MySQL Server]]. Once Photos are added to the final staging area a script will copy them on to '''[[Plum (Photo)]]'''. As they appear on Plum the photos can be displayed or not as defined by the Piwigo software. Also the photos will be copied by the '''[[Backup Server]]''' Strawberry from a NFS share from Plum to Offsite backup.
 
 
==

Revision as of 02:09, 12 March 2025

Introduction

We need a method of easily getting image files uploaded from both LAN and Internet ready to be edited and displayed on the Webservers. For most of the webservers there will not be too many images to be uploaded so direct access with a FTPS server on the webserver host will be good enough. However, for the Plum (Photo) there will be a significant amount of images to be uploaded, it is after all the Piwgo photo webserver and some pre processing and backups will be needed. We expect to do the backups from Backup Server. There will be some changes to the backup server/plum webserver to reverse the storage we will have to change the documentation for them as well.

Photo Management

The general idea is to have an upload server as a staging point to get rid of duplicates, organise metatags and maybe enhance some of the photos and eventually transfer to the Piwigo website on Plum (Photo), we will separate these duties on to this server. To make it all a self contained object we will make this a desktop Unbuntu install rather than the usual server installs. It is uncertain if that is going to be fast enough to actually edit photos but it should be good enough to edit any metatags.

Workflow Outline

The first thing to do is to dump all photos on the physical desktop PC on the 4tb drive it doesn't matter if there are duplicates as they will be addressed as part of this workflow. The important thing is to make sure there are none missing. Once there are photos to upload simply copy them to Satsuma via the SMB shares Import Export, they have been mapped to a pair of network drives (S: is Import and T: is Export). These network shares are on SMB so will only ever work on the LAN and they have been blocked from the internet. The photos are on Satsuma dir /mnt/images/Import and /mnt/images/Export. Once the files are on Satsuma they will be checked for duplicates and previously known, all new unique files will be moved to a separate input directory for processing by Digikam. When there are a few photos the user can login to the plum desktop and start Digikam (I was going to use Shotwell but it would appear that Digikam is a better fit). Digikam should pull the photos an copy them in to its own directory. The user edits the photos or adds tags to them and when finished they should be exported to another staging area to be sent to Plum (Photo). While this leaves us with several copies of the same photos we should be able to have a script periodically delete the various copies, as a long term feature the photos will be left on the Digikam working directory (it is likely that Digikam will show loads of errors if it's working directory is cleared). The running of the various scripts will be tracked with some XML log files to cope with errors. The main processes flow will be tracked by a full database on Mandarin the MySQL Server. Once Photos are added to the final staging area a script will copy them on to Plum (Photo). As they appear on Plum the photos can be displayed or not as defined by the Piwigo software. Also the photos will be copied by the Backup Server Strawberry from a NFS share from Plum to Offsite backup.


==