HiThankfully I have had no problem with installing this plug-in and no problems when testing it so far either. For reference, this is my setup: osTicket Version v1.8.1.2 Server Software Apache/2.4.4 (Win32) OpenSSL/1.0.1e PHP/5.5.3

PHP Version 5.5.3 MySQL Version 5.6.11 Database Space Used 164.61 MiB Database Space for Attachments 1310.81 MiB

 As you can see, my DB was being filled with attachments, making osTicket slow at times and requiring far too long to backup.I have a few questions...1. Now that I am using filesystem storage instead of DB storage, can I move/migrate existing attachments in the DB to the filesystem? (I would like to free up space in my DB for the reasons mentioned above, whilst still having the attachments associated with their respective ticket.)2. Can I specify the format for the filename of the attachment?(I would like the filename to be recorded as it is sent/received in osTicket. This will make it easy to reference via the filesystem should I ever need to locate/delete a file manually. It is currently being stored as a random alphanumerical filename with no file extension.)3. Can I specify the sub-directory within my attachments directory that the attachment it is stored in? (It would be very good if the file storage directories could be created by month>year instead of the default alphabetical structure.)Many thanks.

1. Sure but there is no automated way to do so at this time.  You would have to write your own solution to move them out.2. I believe that the reason your seeing hashes is to prevent people from guessing the file name and just browsing to it. (ie a security concern)  So no, I do not believe that you can.3. The plugin does not have that functionality, its very basic.

1. There is an automated way to migrate: Use the cli appphp setup/cli/manage.php file migrate --backend D --to F2, 3. We are working on extending the CLI app and adding an web-app for the admin panel to find and manage (purging included) attachments. We are also looking to release a retention plugin which can be configured to automatically purge attachments and tickets after a defined period.Cheers,

@[deleted] 1. Thanks, but I have zero PHP coding knowledge and wouldn't want to risk my setup by 'playing around'. 2. My setup is used internally, with no client facing or direct Internet access, so this security measure isn't entirely necessary in this instance - possibly an option to use hash filename security could be a consideration for future plug-in updates. @[deleted]@osticket.com 1. Is this a reliable solution? I consider myself fortunate to have a stable system and don't want to risk breaking anything for a 'nice to have' cleaned-up DB.2. Bring on the updates - they sound good! :)

@[deleted]021, it is designed to be failsafe: the file contents are hashed in transit and afterwards to ensure the contents were successfully written to the new storage backend. In other words, it isn't a hack. The software is shipped with the stock osTicket and uses the AttachmentFile:() function built into the software which will be used by the web-based version when it's available. Furthermore, it's not connected to a particular backend. You can change your mind as often as you like and use migrate as often as you like should you change your mind on where you want your attachments stored. I feel comfortable saying that it is stable. You can add --limit=1 to the argument list to only migrate one file at a time. Do your own assessment and decide if it's "reliable".One caveat for the filesystem storage plugin in particular -- make sure your HTTP server software user has full access to the files once migrated. For instance, if you run Apache as user apache, you might want to do it this waysudo -u apache php setup/cli/manage.php file migrate ...Or just add an ACL rule to the folder where the attachments are stored to ensure that Apache has full access to all the contents. ().Cheers,

We commonly use the file CLI to migrate attachments for closed tickets. This helps keep data available, but offloads data to a cheaper storage system (S3 in our case). We use something like this in a 5-minute scheduled task:php /path/to/manage.php file migrate --status=closed --min-size=8000 --backend=D --to 3 --limit=1The min-size option specifies that attachments under 8000 bytes should stay in the database (this is a comfortable number for BLOB fields saved in InnoDB tables, as it allows MySQL to store all the BLOB data in just one row block), and the status option indicates that only attachments associated with closed tickets should be migrated.Just more food for thought.

Jared this would make a great blog article. ;)

Thanks for taking the time to reply and lay it all out. I actually read your mailer about 1.9 RC and then understood that the CLI App is essentially part of the core code (in my basic understanding), which then negates my concerns; as you subsequently explained. Thanks again.

Also, thanks for maintaining osTicket to the extent that you and them team do. Updates and evolution of the software are much appreciated and valued by myself as a business owner.

2 months later

I was already happy to be able to migrate back and forth but when I run:php setup/cli/manage.php file migrate --backend D --to FI am getting the following error message:PHP Fatal error:  Call to a member function getConfig() on a non-object in /www/htdocs/xxxxxx/ostest/include/class.error.php on line 29Any hint on that ?

Oh by the way I am using v.1.9.2

a year later

Hello, can somebody describe, how to use CLI on v1.9.12?

The cli has a help command that shows you the possibilities:php manage.php file -hYou find the manage.php in the folder /setup/cli/

4 days later

@[deleted]osticket# php /path/to/osTicket-v1.9.12_default/upload/setup/cli/manage.php file -hreturns: <html></html>

@[deleted]Weird. In my test environment I'm using this command php /opt/bitnami/apache2/htdocs/osticket-1912/setup/cli/manage.php file -h and getting this output:CLI file manager for osTicketUsage:    /opt/bitnami/apache2/htdocs/osticket-1912/setup/cli/manage.php file action Options:    -b BK, --backend=BK Search by file backend. See `backends` action for a                        list of available backends    -f FILE, --file=FILE                        Filename used for import and export    -F id, --file-id=id Search by file id    -h, --help          Display this help message    -L count, --limit=count                        Limit search results to this count    -Z SIZE, --max-size=SIZE                        Search for files smaller than this. k, M, G are                        welcome    -z SIZE, --min-size=SIZE                        Search for files larger than this. k, M, G are welcome    -N name, --name=name                        Search by file name (subsring match)    -S STATUS, --status=STATUS                        Search on ticket state (`open` or `closed`)    -T id, --ticket=id  Search by internal ticket id    -m BK, --to=BK      Target backend for migration. See `backends` action                        for a list of available backends    -v, --verbose       Be more verboseArguments:action    Action to be performed        list - List files matching criteria        export - Export files from the system        import - Load files exported via `export`        zip - Create a zip file of the matching files        dump - Dump file content to stdout        load - Load file contents from stdin        migrate - Migrate a file to another backend        backends - List configured storage backends        expunge - Remove matching files from the systemDo you really run it from the command line?

a year later

Hello, is there any way to use cli app or making the files export without command line? This is because my hosting does not supply command line access. I have cpanel. I tried with a cron job but the job output says "Management only supported from command-line"Thank you!

Write a Reply...