- 15 Jun, 2021 1 commit
-
-
- 02 Jun, 2021 1 commit
-
-
- 26 Jan, 2021 1 commit
-
-
Michael Davis authored
Adds fields for tape verification to Workflow message
-
- 13 Sep, 2019 1 commit
-
-
Cedric CAFFY authored
Added files and bytes count for Retrieved files from User or Repack in the "tape session finished" message Made the Repack system test clearer by printing steps and by adding folders for the reports
-
- 11 Oct, 2016 1 commit
-
-
Victor Kotlyar authored
6b6374d6c2e209c98c0d4d7aa665e1df83d71aaa CASTOR-5350: Introduce encryption SCSI commands in tape drive backend Implementation of two methods: * setEncryptionKey(key): Sets encryption params to drive. * clearEncryptionKey: Clears encryption params from drive. 3cf91d48f5c7b0cb563c3037aee69ec769f5ab94 Added support for an interface script that will setup drive encryption per tape e9ca601687508de20fab7154e63bb0dbd1b25a8a Migrate TapeWriteSingleThread::TapeCleaning::~TapeCleaning() body to .cpp 266b02d8175b5cfc0b688135cbdc335e93060b CASTOR-5350: Refactor support for only external key management script 789b26a0bc69053ff1ab792a02676a7753f093ed Merge branch 'encryption_backend' into 'master' CASTOR-5350: Encryption backend ## Description The aim of this merge request is to incorporate encryption support into CASTOR. The proposed changes are to be used in conjunction with the operators' [ExternalEncryptionKeyScript](https://gitlab.cern.ch/slaskari/castor-get-encryption-key). The **aim** is to enable encryption in specific tape pools of CASTOR. ## Changes * Introduce encryption SCSI backend to DriveGeneric. * Introduce encryption control wrapper * (`castor/tape/tapeserver/daemon/EncryptionControl`) for * abstracting the two sub-components of: * Calling the `ExternalEncryptionKeyScript`, * Calling the equivalent DriveGeneric function for * passing/clearing the encryption parameters to/from the drive. * Add new configuration option in `castor.conf` for the external key * management script. * Create a Subprocess wrapper for executing external commands as * CASTOR children (`castor/server/Subprocess.{h,c}pp`). * Incorporate encryption handling in the: * DataTransferSession * LabelSession * CleanerSession * Add encryption control timer in the task Watchdog. See merge request !1 fa550707c42d80466bbd448e355aaf9be5ea8e04 Clear encryption key only when encryption enabled Changes include: - Making EncryptionControl stateful - Calling clearEncryptionKey on the drive only when encryption is on. Also includes a minor duplicate code fix on DriveGeneric. cf4eb9f3ae36c9cfc9c40349d69ab6642020e81e Merge branch 'encryption_changes' into 'master' Clear encryption key only when encryption enabled ## Description Changes include: - Making EncryptionControl stateful - Calling `clearEncryptionKey()` on the drive only when encryption is on. Also includes a minor duplicate code fix on **DriveGeneric.cpp**. See merge request !2 40366d963ee33ca081df6c991189b21369e461fd Check if the drive has encryption capability enabled: * Add isEncryptionCapEnabled() vendor-specific function * Check isEncryptionCapEnabled() before passing encryption params * Check isEncryptionCapEnabled() before clearing encryption params * Clear encryption key before unencrypted I/O 4ccc661d01eccfc3fdfb9ee2578d15a147a0c55a Merge branch 'encryption_capability_enabled' into 'master' Drive encryption capabilities inclusion ## Description The aim of this merge request is to address issues related to encryption on drive without the encryption capability enabled. More specifically: * It introduces a vendor-specific way of identifying if the drive * has encryption capability enabled * **IBM**: Through the SPIN index SCSI page * **Oracle**: Through the general INQUIRY SCSI page * If the data to be written are to be encrypted, an additional check * of the encryption capability of the drive is made. In case of * encrypted data, but no encryption capability, the session fails. In essence, all encryption related operations are made modulo the encryption capability of the drive. Last, in case of unencrypted I/O, we clear the keys of the drive (if encryption capable) to avoid encrypted data with previous keys on CASTOR's system failure. ## Testing Before the merge request's submission, the following tests were passed: On drives with **encryption capability enabled**: * Label session * Label with previously set encryption key * Write without encryption * Read without encryption * Write with encryption * Read with encryption * Write with previously set encryption key * Read with previously set encryption key On drive with **encryption cabability disabled**: * Label session * Write without encryption * Read without encryption * Write with encryption - session **should** fail * Read with encryption - session **should** fail See merge request !3 55b85a2cb4681d697565116c00ff98c6becea4fb Secure session against invalid encryption script output 3a54875c680fe6c1c9d5cf25cf98d2780196e0d1 Changes in encryption workflow - VMGR tag is updated only on write operations - Empty key signifies no encryption f5408cf0ccbae9a4ab94a533f3b6d7be323f72fb Minor encryption log enhancements * Error line in Read/Write session with ErrorMesage key * Fix for delimiter in the end of arguments in argsToString() 2e7204fb0dd24b472a959fa5e13320c34df4f017 Merging in improvements on tape encryption support. 92533a1746d0744ee528781558a720c63ca3c4d1 Removed nullptr which is not supported in SLC6's gcc. Added automatic deletion of json objects in EncryptionControl::parse_json_script_output. fca3bb9e7fce364b429fc0b5c036fb752fd67ff1 Fix log typo
-
- 06 Oct, 2016 1 commit
-
-
Victor Kotlyar authored
CASTOR-4836: tapeserverd should have a new time counter: delivery time Fixed. Add two counters: deliveryTime and drainingTime. For the recall session deliveryTime is the total time of the disk threads and drainigTime is the time difference between deliveryTime and the total time of the tape thread or in other words how much time disk threads spent after the tape thread finished. For the migration session deliveryTime is the total time of the tape thread and drainingTime always equal 0.
-
- 16 Jul, 2015 2 commits
-
-
Steven Murray authored
-
Steven Murray authored
Renamed CTA/tapeserver/castor to CTA/tapeserver/castor_checkout in preparation for the moving the sub-directory CTA/tapeserver/castor/castor up the directory tree
-
- 15 Jul, 2015 2 commits
-
-
Steven Murray authored
-
Eric Cano authored
-
- 05 Dec, 2014 1 commit
-
-
Eric Cano authored
a new composite transferTime (member function) which now matches better the previous definition of transfeTime.
-
- 10 Nov, 2014 1 commit
-
-
Eric Cano authored
CASTOR-4823: tapeserverd's main process should log statistics and status of the closing session in all cases Added new messages between the session process and the main process: addition and removal of log parameters. Added storage of the log parameters in the catalogueTransferSession. Added logging of the tape session at the end in the initial process, allowing statistics gathering even in case of crash. This standard log message is intended to be used as an input for the tape log system. Changed the default off the formatting of doubles in the log so that we don't end up with hard to parse scientific notation in the logs.
-
- 28 Oct, 2014 1 commit
-
-
Eric Cano authored
The offending message has been changed in a previous case: CASTOR-4749 Reviewed all bandwidth calculations to homogenize the statistics printing. Fixed a bug where the total time for a session was not properly retrieved before logging, leading to NaN printouts.
-
- 25 Jul, 2014 1 commit
-
-
David COME authored
-
- 16 Jul, 2014 1 commit
-
-
David COME authored
-
- 15 Jul, 2014 1 commit
-
-
David COME authored
-
- 09 Jul, 2014 2 commits
- 07 Jul, 2014 1 commit
-
-
Eric Cano authored
Only one applies at a time in read or write context, but the naming will make the code more undrestandable.
-
- 04 Jul, 2014 1 commit
-
-
Eric Cano authored
-