Merge branch 'development' into development_py36

debian/changelog

@@ -1,12 +1,29 @@
-metpx-sr3 (3.00.55rc2) stable; urgency=medium
+metpx-sr3 (3.00.56rc1) unstable; urgency=medium
 
-  * fix #1219 correct date conversion.
-  * fix #1214 scheduling refactor addresses a regression found in rc1
+  * NEW option *recusion* option ( #1237 ) (actually restored, was removed.)
+  * fix #1156 - NEW option *logDuplicates* 
+  * NEW EXPERIMENTAL option: *logJson*
+  * fix #1223 Switch from global QoS to per-consumer.
+  * AM sender problems identified in satnet testing.
+  * working on #35 augmenting .qname with subscriptions.json state file.
+  * working on #1183, sr3 manages instances > 100 correctly.
+  * PR #1228 Unquote secret_access_key in s3CloudSender plugin
+  * PR #1230 ... reduced spurious "unknown options" messages from config.
+  * fix #1199 - directory /  not interpreted properly.
+  * fix #1246 delete source when no options given
+
+ -- SSC-5CD2310S60 <[email protected]>  Tue, 08 Oct 2024 10:42:37 -0400
+
+metpx-sr3 (3.00.55post1) unstable; urgency=medium
+
+  * fix #1242 sftp creates directories when it should not.
 
- -- SSC-5CD2310S60 <[email protected]>  Thu, 12 Sep 2024 15:16:55 -0400
+ -- peter <[email protected]>  Sat, 28 Sep 2024 00:51:47 -0400
 
-metpx-sr3 (3.00.55rc1) unstable; urgency=medium
+metpx-sr3 (3.00.55) unstable; urgency=medium
 
+  * fix #1219 correct date conversion.
+  * fix #1214 scheduling refactor addresses a regression found in rc1
   * fix #953 sr3 status queue size updates again.
   * fix #1157 transfer/stat() call improves behaviour with overly dynamic data.
   * fix #1209 Added *schedule_time* to scheduled flows (and polls)
@@ -25,8 +42,14 @@ metpx-sr3 (3.00.55rc1) unstable; urgency=medium
   * fix #1217 one minute of wiggle room when scheduled flows come due.
   * fix #1218 permissions of directories created by senders. 
 
+ -- SSC-5CD2310S60 <[email protected]>  Tue, 23 Sep 2024 09:47:36 -0400
+
+metpx-sr3 (3.00.54post2) unstable; urgency=medium
+
+  * 3.00.54post1 package generation on launchpad failed, re-uploading as post2
+  * fix for crash in fileAgeMin
 
- -- SSC-5CD2310S60 <[email protected]>  Tue, 11 Sep 2024 11:24:36 -0400
+ -- SSC-5CD2310S60 <[email protected]>  Wed, 21 Aug 2024 11:49:45 -0400
 
 metpx-sr3 (3.00.54) unstable; urgency=medium
 

docs/source/Explanation/DeploymentConsiderations.rst

@@ -147,6 +147,47 @@ Security Considerations
 This section is meant to provide insight to those who need to perform a security review
 of the application prior to implementation.
 
+
+Architecture
+~~~~~~~~~~~~
+
+Sarracenia can be a component in many solutions, and can be deployed as a cloud component.
+However, in it's rawest, simplest form, Sarracenia is not used like cloud services, where 
+one service is accessible from anywhere. It is more of a component or toolkit that is 
+expected to work with traditional network security zoning. Rather than have one service 
+for all, and requiring traffic/firewall exceptions and external security scanning to 
+intercept traffic, one deploys pump at each network zone demarcation. 
+
+Data is delivered to the pump at the demarcation point, and then another pump
+forwards data to the next zone. As part of demarcation processing, one can download a 
+file, run it through processing, such as malware scanning, and then only announce 
+it's availability to the following pump if it's ok.
+
+Each pump has independent authentication, and pump administrators 
+and users can define what traffic is made available to users on the other side of 
+the demarcation point. Pumps are chained together by copying from one to the next 
+to the next, where each one can have different access, purpose, and ownership.
+
+No formal federation or whole network identity is needed to pass data around 
+the network. Instead, each pump establishes authentication for the neigbouring pump. 
+If countries operated data pumps, one could imagine a situation like the following:
+The Russians and Americans want to transfer data but do not want to be exposed to each
+others' servers directly. The Russians could share with Kazakstan, The Kazakhs exchange
+with Korea, and Korea exchanges with Canada. The Americans only need to have
+a good relationship with the Canadians or Koreans. Each link in the chain 
+exposing themselves directly only to peers they have an explicit and 
+agreed relationship with. Each link in the chain can perform their own
+scanning and processing before accepting the data.
+
+.. image:: Concepts/sr3_flow_example.svg
+    :scale: 100%
+    :align: center
+
+In this example, you can see that there are the ddsr pumps deployed on internal
+operations zones, and they push or pull from pumps in other zones, such as another
+operations zone, or a public access zone. Pumps are expected to 
+mediate traffic travelling between network zones.
+
 Client
 ~~~~~~
 

docs/source/How2Guides/UPGRADING.rst

@@ -39,6 +39,21 @@ Installation Instructions
 git
 ---
 
+3.0.56
+------
+
+*CHANGE*: code refactor *sarracenia.credentials...* classes are now 
+*sarracenia.config.credentials* any code using credentials need to be
+updated.
+
+*CHANGE*: queue settings stored in subscriptions.json state file,
+instead of a .qname file, along with more information. Transition
+is perhaps complex. This version will read and write both files,
+so as to preserve ability to downgrade. later version will drop
+support for qname files.
+
+
+
 3.0.54
 ------
 

docs/source/Reference/sr3_options.7.rst

@@ -1089,6 +1089,19 @@ to control what is written to log files.  The format is documented here:
 * https://docs.python.org/3/library/logging.html#logrecord-attributes
 
 
+logJson <flag> (default: False) EXPERIMENTAL
+--------------------------------------------
+
+when *logJson on* is set, a second log file with the .json extension is made beside the
+normal .log file.  Each line of the .json logs is a .json structure, containing 
+a message written by the flow log. It does not contain unformatted output of
+sub-shells, and plugins which may produce arbitrary output.
+
+The .log file will contain the output of sub-programs launched by the flow, 
+and the .json will only contain properly formatted log messages from the application itself
+and properly written callbacks (that use normal python logging mechanisms.)
+
+
 logLevel ( default: info )
 --------------------------
 
@@ -1596,6 +1609,14 @@ given. This option also enforces traversing of symbolic links.
 This option is being used to investigate some use cases, and may disappear in future.
 
 
+recursive <flag> (default: on)
+------------------------------
+
+when scanning a path (for poll, post, cpost, or watch) if you encounter a directory
+do you include it's contents as well? To only scan the specified directory
+and no sub-directories, specify *recursive off*
+
+
 rename <path>
 -------------
 
@@ -1771,7 +1792,7 @@ appropriately.
 
 
 scheduled_interval,scheduled_hour,scheduled_minute,scheduled_time
---------------------------------------------------
+-----------------------------------------------------------------
 
 When working with scheduled flows, such as polls, one can configure a duration
 (no units defaults to seconds, suffixes: m-minute, h-hour) at which to run a 
@@ -1798,7 +1819,7 @@ this will poll the data at 15:30, 16:30 and 18:59 every day. This option allows
 your time field then previous options.
 
 sendTo <url>
----------------
+------------
 
 Specification of a remote resource to deliver to in a sender.
 
@@ -2079,10 +2100,10 @@ Examples: Canada/Pacific, Pacific/Nauru, Canada/Eastern, Europe/Paris
 Has no effect other than in when polling an FTP server.
 
 
-tlsRigour (default: medium)
+tlsRigour (default: normal)
 ---------------------------
 
-tlsRigour can be set to: *lax, medium, or strict*, and gives a hint to the
+tlsRigour can be set to: *lax, normal, or strict*, and gives a hint to the
 application of how to configure TLS connections. TLS, or Transport Level
 Security (used to be called Secure Socket Layer (SSL)) is the wrapping of
 normal TCP sockets in standard encryption. There are many aspects of TLS

docs/source/fr/CommentFaire/MiseANiveau.rst

@@ -38,6 +38,20 @@ Instructions d’installation
 git
 ---
 
+3.0.56
+------
+
+*CHANGEMENT* : refactorisation du code *sarracenia.credentials...* les classes sont désormais
+*sarracenia.config.credentials* tout code utilisant des informations d'identification doit être
+mis à jour.
+
+*CHANGEMENT* : paramètres de file d'attente stockés dans le fichier d'état subscriptions.json,
+au lieu d'un fichier .qname, avec plus d'informations. La transition
+est peut-être complexe. Cette version lira et écrira les deux fichiers,
+afin de préserver la possibilité de rétrogradation. La version ultérieure abandonnera
+la prise en charge des fichiers qname.
+
+
 3.0.54
 ------
 

docs/source/fr/Explication/ConsiderationsDeployments.rst

@@ -167,6 +167,46 @@ Considérations de sécurité
 Cette section a pour but de donner un aperçu à ceux qui ont besoin d'effectuer un examen de sécurité.
 de l'application avant la mise en œuvre.
 
+Architecture
+~~~~~~~~~~~~
+
+Sarracenia peut être un composant de nombreuses solutions et peut être déployé en tant que composant cloud.
+Cependant, dans sa forme la plus brute et la plus simple, Sarracenia n'est pas utilisé comme les services cloud, où
+un service est accessible de n'importe où. Il s'agit plutôt d'un composant ou d'une boîte à outils qui est
+censé fonctionner avec le zonage de sécurité réseau traditionnel. Plutôt que d'avoir un service
+pour tous et d'exiger des exceptions de trafic/pare-feu et une analyse de sécurité externe pour
+intercepter le trafic, on déploie une pompe à chaque démarcation de zone réseau.
+
+Les données sont livrées à la pompe au point de démarcation, puis une autre pompe
+transmet les données à la zone suivante. Dans le cadre du traitement de démarcation, on 
+peut télécharger un fichier, l'exécuter via un traitement, comme une analyse des logiciels 
+malveillants, puis annoncer sa disponibilité à la pompe suivante uniquement si elle est correcte.
+
+Chaque pompe dispose d'une authentification indépendante, et les administrateurs de pompe
+et les utilisateurs peuvent définir le trafic mis à disposition des utilisateurs de l'autre côté
+du point de démarcation. Les pompes sont enchaînées en copiant de l'une à l'autre
+à l'autre, où chacune peut avoir un accès, un but et une propriété différents.
+
+Aucune fédération formelle ou identité de réseau complet n'est nécessaire pour transmettre des données
+sur le réseau. Au lieu de cela, chaque pompe établit une authentification pour la pompe voisine.
+Si les pays exploitaient des pompes de données, on pourrait imaginer une situation comme celle-ci :
+Les Russes et les Américains veulent transférer des données mais ne veulent pas être exposés directement aux serveurs
+des autres. Les Russes pourraient partager avec le Kazakhstan, les Kazakhs échanger
+avec la Corée et la Corée échanger avec le Canada. Les Américains n'ont besoin que d'avoir
+une bonne relation avec les Canadiens ou les Coréens. Chaque maillon de la chaîne
+s'expose directement uniquement aux pairs avec lesquels il a une relation explicite et
+convenue. Chaque maillon de la chaîne peut effectuer sa propre analyse et son propre traitement avant d'accepter les données.
+
+.. image:: Concepts/sr3_exemple_de_flux.svg
+    :scale: 100%
+    :align: center
+
+Dans cet exemple, vous pouvez voir que les pompes DDR sont déployées sur des zones d'opérations
+internes et qu'elles poussent ou tirent depuis des pompes situées dans d'autres zones, telles qu'une autre
+zone d'opérations ou une zone d'accès public. Les pompes sont censées
+servir de médiateur au trafic circulant entre les zones du réseau.
+
+
 Client
 ~~~~~~
 

docs/source/fr/Reference/sr3_options.7.rst

@@ -1083,6 +1083,17 @@ de python. Le format est documenté ici:
 
 * https://docs.python.org/fr/3/library/logging.html#logrecord-attributes
 
+logJson <flag> (par défaut : faux) EXPÉRIMENTAL
+------------------------------------------------
+
+lorsque *logJson on* est défini, un deuxième fichier journal avec l'extension .json est créé à côté du
+fichier .log normal. Chaque ligne des journaux .json est une structure .json, contenant
+un message écrit par le journal de flux. Il ne contient pas de sortie non formatée
+des sous-shell et des plugins qui peuvent produire une sortie arbitraire.
+
+Le fichier .log contiendra la sortie des sous-programmes lancés par le flux,
+et le .json ne contiendra que les messages de journal correctement formatés provenant de l'application elle-même
+et des rappels correctement écrits (qui utilisent des mécanismes de journalisation python normaux.)
 
 logLevel ( défaut: info )
 -------------------------
@@ -1587,8 +1598,12 @@ donné. Cette option impose également la traversée de liens symboliques.
 
 Cette option est utilisée pour étudier certains cas d'utilisation et pourrait disparaître à l'avenir.
 
+<flag> recursive (par défaut : activé)
+--------------------------------------
 
-
+Lors de l'analyse d'un chemin (pour un *poll*, une *post*, un *cpost* ou un *watch*), si vous 
+rencontrez un répertoire, incluez-vous également son contenu ? Pour analyser uniquement le répertoire spécifié
+et aucun sous-répertoire, spécifiez *recursive off*
 
 rename <chemin>
 ---------------
@@ -1770,8 +1785,8 @@ sanity_log_dead <intervalle> (défaut: 1.5*housekeeping)
 
 L’option **sanity_log_dead** définit la durée à prendre en compte avant de redémarrer un composant.
 
-scheduled_interval,scheduled_hour,scheduled_minute
---------------------------------------------------
+scheduled_interval,scheduled_hour,scheduled_minute,scheduled_time
+-----------------------------------------------------------------
 
 Lorsque vous travaillez avec des flux cédulés, tels que des sondages, vous pouvez configurer une durée
 (unité: seconde par défaut, suffixes : m-minute, h-heure) à laquelle exécuter un
@@ -2063,10 +2078,10 @@ exemples: Canada/Pacific, Pacific/Nauru, Europe/Paris
 Seulement actif dans le contexte de sondage de serveur FTP.
 
 
-tlsRigour (défaut: medium)
+tlsRigour (défaut: normal)
 --------------------------
 
-*tlsRigour* peut être réglé a : *lax, medium ou strict*, et donne un indice à l'application par rapport à la
+*tlsRigour* peut être réglé a : *lax, normal ou strict*, et donne un indice à l'application par rapport à la
 configuration des connexions TLS. TLS, ou Transport Layer Security (autrefois appelée Secure Socket Layer (SSL))
 est l’encapsulation de sockets TCP normales en cryptage standard. Il existe de nombreux aspects de
 négociations TLS, vérification du nom d’hôte, vérification des certificats, validation, choix de

sarracenia/__init__.py

@@ -417,13 +417,17 @@ def durationToSeconds(str_value, default=None) -> float:
     206: "Partial Content: received and inserted.",
     304: "Not modified (Checksum validated, unchanged, so no download resulted.)",
     307: "Insertion deferred (writing to temporary part file for the moment.)",
-    410: "Gone: server data different from notification message",
+    404: "Not Found: no pattern match",
+    406: "Not Acceptable: file older than fileAgeMax",
+    410: "Gone: file too old",
     417: "Expectation Failed: invalid notification message (corrupt headers)",
     422: "Unprocessable Content: could not determine path to transfer to",
+    425: "Too Early: file younger than fileAgeMin",
     499: "Failure: Not Copied. SFTP/FTP/HTTP download problem",
     #FIXME : should  not have 503 error code 3 times in a row
     # 503: "Service unavailable. delete (File removal not currently supported.)",
     503: "Unable to process: Service unavailable",
+    504: "Gateway Timeout: message too old"
     # 503: "Unsupported transport protocol specified in posting."
 }
 
@@ -563,7 +567,8 @@ def deriveSource(msg,o):
             pass
         elif source:
             msg['source'] = source
-            msg['_deleteOnPost'] |= set(['source'])
+        elif 'source' in msg:
+            del msg['source']
 
     def deriveTopics(msg,o,topic,separator='.'):
         """

sarracenia/_version.py

@@ -1 +1 @@
-__version__ = "3.00.55rc2"
+__version__ = "3.00.56rc1"