Jump to content

Mark Derbecker

Seeq Team
  • Posts

    21
  • Joined

  • Last visited

  • Days Won

    3

Mark Derbecker last won the day on January 21 2021

Mark Derbecker had the most liked content!

1 Follower

Personal Information

  • Company
    Seeq Corporation
  • Title
    VP of Engineering
  • Level of Seeq User
    Seeq Super-User

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Mark Derbecker's Achievements

Rookie

Rookie (2/14)

  • Reacting Well
  • Collaborator Rare
  • First Post
  • Week One Done
  • One Month Later

Recent Badges

5

Reputation

  1. Hi Nate, There are currently no storage retention limitations on such data. Seeq stores this data in its main data storage area (along with workbook definitions, calculation definitions etc). Seeq is not meant to be a "system of record" for pushed data -- we recommend that you always retain the ability to recreate this data from original sources if necessary. But to be clear, Seeq will currently not pare down this data using any sort of retention policy. Mark
  2. Frequently Asked Questions regarding the Log4Shell vulnerability and Seeq Does Seeq or any of its constituent 3rd-party components use Log4J? No. Seeq uses a library called Logback, which is not vulnerable to the high-criticality Log4Shell exploit (CVE-2021-44228). There is a related vulnerability (CVE-2021-42550) in Logback that the security community has deemed as medium criticality given that it requires access to logback's configuration file by the attacker, sign of an already compromised system. According to Seeq's 3rd Party Vulnerability assessment process, CVE-2021-42550 has been assessed as low criticality in the context of the Seeq system but the library will nonetheless be upgraded as part of an upcoming Seeq point release. My virus scanner is flagging log4j-over-slf4j-1.7.7.jar as vulnerable. What's up with that? Virus scanners, depending on their level of sophistication, may flag a file named cassandra/files/lib/log4j-over-slf4j-1.7.7.jar in the Seeq installation folder for Seeq versions R50 and older. This component does not suffer from the Log4Shell vulnerability, it is an adapter layer that is only used if Log4J is also used somewhere in the system. See http://slf4j.org/log4shell.html for more information. The component was part of the Cassandra NoSQL database system, a sub-component of the overall Seeq system in versions R50 and earlier. Cassandra has been removed in R51 and later. I see something called log4js and log4javascript in the webserver folder of the Seeq installation. What about that? Those files are related to a Javascript library that performs a similar logging function as Log4j but does not contain the vulnerability. More information: https://github.com/log4js-node/log4js-node/issues/1105
  3. You're doing the right thing Ivan. SPy should have a better avenue for handling enums. I've logged a feature request, and internally we're tracking it as CRAB-23208.
  4. It should be available: https://pypi.org/project/seeq/0.48.6.167/ You can do pip install -U seeq==0.48.6.167 to force it.
  5. Hi Felix, you unfortunately hit a bug that I introduced in SPy versions 165-166. It's fixed in 167. You can do `pip install -U seeq~=0.48.6` to get the latest.
  6. Hi Felix, is it possible for you to upgrade to Python 3.7+? That will fix the problem. I'm hoping to use Python 3.7 features in SPy from here forward so that we can make the library more modern with type annotations.
  7. Thorsten, I tracked this down to a non-obvious issue with your initial push wherein you specified `Value Unit of Measure` instead of `Value Unit Of Measure`. (Notice the case difference on the word "of".) Unfortunately due to another issue with Seeq Server, once you push with the wrong case, the signal becomes "tainted" and you can't make any changes to it via a normal spy.push. As you found, you can only archive it with the SDK. I'm going to add appropriate guards and error messages to spy.push() that prevent inadvertent use of the wrong case, and I'll also log a bug report in our system to fix Seeq Server.
  8. Ahhh, yes I see. That won't work because it's rejecting the overall POST. I'll think about how to possibly fix.
  9. With respect to archiving, I think if you change `Archived` to `True` in the DataFrame and then `spy.push()` that item, it should mark it as Archived. Have you tried that? Note that the `spy.push(archive)` argument is a little misleading-- it is used for another purpose. I'll think about whether to rename that for clarity.
  10. Hi Thorsten, In an upcoming version of Seeq Server (R22.0.46.xx) it will be possible for SPy to verify units prior to pushing. (We needed to fix a problem in the REST API that was preventing SPy from querying Seeq Server for the list of supported units.) I'll circle back to this thread to notify when SPy has the capability, but keep in mind that you will need to upgrade Seeq Server as well. Mark
  11. I see that mistake Thorsten, we'll fix it. Thanks for reporting it.
  12. Thorsten, SPy module version 136 has a fix for the timezone issue, you can upgrade if you'd like to try it out.
  13. Hi Thorsten, I think something's amiss with how we handle timezones when start and end are omitted. `result1` is in a timezone offset that is one hour different from `result2`, and is therefore in the future where there is no data ... I'll investigate.
  14. This is being internally tracked as CRAB-13788
  15. Yeah OK--- I'll log a feature request in our system for a quick toggle.
×
×
  • Create New...