profile
viewpoint

nijet99/FLAC-Convert 39

Incremental convertion of flac files into mp3 (320/v0/v2), ogg and aac files using bash

tobbez/deluge_exporter 23

Prometheus exporter for the Deluge BitTorrent client

tobbez/everything-efu-gen 6

Utility for generating file lists (EFU files) for VoidTools’ search utility Everything

blambi/Gruvdrift 4

Page and services for a minecraft comunity

ozamosi/river 4

Podcast client daemon

tobbez/dnsstatd 2

A DNS server statistics collector

tobbez/h-vanira 2

Small, simple, and modular IRC channel guard bot

tobbez/chrome-autoreload-crashed 1

Chrome extension for automatically reloading crashed tabs

tobbez/FileHippoUpdateDownloader 1

Utility that downloads updates found by the FileHippo Update Checker

tobbez/gkatom 1

Unofficial but actually usable atom feed for Gunnerkrigg Court

issue commenttobbez/deluge_exporter

Vulnerabilities in Docker image

This is a good demonstration of the problem with CVE scanners. None of the issues cited have any impact here:

  • The busybox issues require that the attacker is already able to run shell commands.
  • The libuuid issue is thought to not be exploitable and has been disputed. Even if it were exploitable, the affected code from util-linux (where libuuid is developed) is not even included in libuuid.
  • The ssl_client issues are just repeated from busybox, as it's built from busybox source.

In any case, I have enabled weekly automatic rebuilds of all images (34e4e120e7fdd177bcf4000e1daaa24996858756).

ngosang

comment created time in a day

issue closedtobbez/deluge_exporter

Vulnerabilities in Docker image

Just update the base Docker Image.

https://github.com/anchore/grype

grype tobbez/deluge_exporter:2.4.0
 ✔ Vulnerability DB        [no update available]
 ✔ Pulled image            
 ✔ Loaded image            
 ✔ Parsed image            
 ✔ Cataloged packages      [42 packages]
 ✔ Scanned image           [23 vulnerabilities]
NAME        INSTALLED  FIXED-IN   VULNERABILITY   SEVERITY 
busybox     1.33.1-r3  1.33.1-r4  CVE-2021-42374  Medium    
busybox     1.33.1-r3  1.33.1-r5  CVE-2021-42375  Medium    
busybox     1.33.1-r3  1.33.1-r6  CVE-2021-42378  High      
busybox     1.33.1-r3  1.33.1-r6  CVE-2021-42379  High      
busybox     1.33.1-r3  1.33.1-r6  CVE-2021-42380  High      
busybox     1.33.1-r3  1.33.1-r6  CVE-2021-42381  High      
busybox     1.33.1-r3  1.33.1-r6  CVE-2021-42382  High      
busybox     1.33.1-r3  1.33.1-r6  CVE-2021-42383  High      
busybox     1.33.1-r3  1.33.1-r6  CVE-2021-42384  High      
busybox     1.33.1-r3  1.33.1-r6  CVE-2021-42385  High      
busybox     1.33.1-r3  1.33.1-r6  CVE-2021-42386  High      
libuuid     2.37-r0    2.37.2-r0  CVE-2021-37600  Medium    
ssl_client  1.33.1-r3  1.33.1-r4  CVE-2021-42374  Medium    
ssl_client  1.33.1-r3  1.33.1-r5  CVE-2021-42375  Medium    
ssl_client  1.33.1-r3  1.33.1-r6  CVE-2021-42378  High      
ssl_client  1.33.1-r3  1.33.1-r6  CVE-2021-42379  High      
ssl_client  1.33.1-r3  1.33.1-r6  CVE-2021-42380  High      
ssl_client  1.33.1-r3  1.33.1-r6  CVE-2021-42381  High      
ssl_client  1.33.1-r3  1.33.1-r6  CVE-2021-42382  High      
ssl_client  1.33.1-r3  1.33.1-r6  CVE-2021-42383  High      
ssl_client  1.33.1-r3  1.33.1-r6  CVE-2021-42384  High      
ssl_client  1.33.1-r3  1.33.1-r6  CVE-2021-42385  High      
ssl_client  1.33.1-r3  1.33.1-r6  CVE-2021-42386  High

closed time in a day

ngosang

push eventtobbez/deluge_exporter

Torbjörn Lönnemark

commit sha 34e4e120e7fdd177bcf4000e1daaa24996858756

ci: Rebuild containers weekly

view details

push time in 2 days

push eventtobbez/deluge_exporter

Torbjörn Lönnemark

commit sha a1a8ed0634e73435115aa3ce148b5cd82fe90d30

ci: Rebuild containers weekly

view details

push time in 2 days

push eventtobbez/deluge_exporter

Torbjörn Lönnemark

commit sha 4967080a7caef4dd93d72b1716fdd6047eb91a51

ci: Rebuild containers weekly

view details

push time in 2 days

push eventtobbez/deluge_exporter

Torbjörn Lönnemark

commit sha 625103e4814acf757e3860044649b6b847df9847

ci: Rebuild containers weekly

view details

push time in 2 days

push eventtobbez/deluge_exporter

push time in 3 days

push eventtobbez/deluge_exporter

Torbjörn Lönnemark

commit sha 41b592bbca64f25e819554c63c09440b7fa9a05c

ci: Rebuild containers weekly

view details

push time in 3 days

push eventtobbez/deluge_exporter

Torbjörn Lönnemark

commit sha f585125fbd2b35996ed683dcabb4bf86ba1f9615

ci: Rebuild containers weekly

view details

push time in 3 days

push eventtobbez/deluge_exporter

Torbjörn Lönnemark

commit sha 775d28b11a72265b6faefab40efbe8f32b0628d5

ci: Use actions/checkout@v2

view details

push time in 3 days

create barnchtobbez/spack

branch : p7zip-gcc11

created branch time in 7 days

PR opened spack/spack

p7zip: fix build on gcc 11

Fixes the following build failure when building with gcc 11:

     478    ../../../../CPP/7zip/Archive/Wim/WimHandler.cpp: In member function 'virtual LONG NArchive::NWim::CHandler::GetArchiveProperty(PROPID, PROPVARIANT*)':
  >> 479    ../../../../CPP/7zip/Archive/Wim/WimHandler.cpp:308:11: error: use of an operand of type 'bool' in 'operator++' is forbidden in C++17
     480      308 |           numMethods++;
     481          |           ^~~~~~~~~~
  >> 482    ../../../../CPP/7zip/Archive/Wim/WimHandler.cpp:318:9: error: use of an operand of type 'bool' in 'operator++' is forbidden in C++17
     483      318 |         numMethods++;
     484          |         ^~~~~~~~~~
+23 -0

0 comment

2 changed files

pr created time in 7 days

issue closedtobbez/deluge_exporter

deluge connecting information

Wanted to leave a note about the User you need to connect with as I ran into an issue using a user of Normal Level 5 I needed to connect with a user of Admin Level 10 according to https://dev.deluge-torrent.org/wiki/UserGuide/Authentication when connecting with a Normal user, I did not see any errors in exporter logs, but metrics reported as 0. Once I connected with an Admin Level user, I was able to get metrics.

Anyhow great project, thanks for the hard work!

closed time in a month

sinicide

issue commenttobbez/deluge_exporter

deluge connecting information

Normal users can only see information for torrents they themselves added to a deluge instance, while administrators can see information for all torrents in the instance.

This means the account used for the exporter has to be either:

  • the same account you use when using deluge normally, or
  • an admin account

In short: if an account can see the torrents when connecting using the deluge client, then metrics for those torrents will be reported when using that account in the exporter.

Note that this only applies for the torrent count metrics (deluge_torrents, deluge_torrents_by_label). All other metrics are tracked globally for an instance and are available regardless of authentication level.

sinicide

comment created time in a month

Pull request review commentprometheus/snmp_exporter

Hacky workaround for net-snmp version detection

 package main #cgo CFLAGS: -I/usr/local/include #include <net-snmp/net-snmp-config.h> #include <net-snmp/mib_api.h>+#include <net-snmp/types.h>+#include <net-snmp/library/container.h>+#include <net-snmp/agent/snmp_agent.h>+#include <net-snmp/agent/snmp_vars.h>

Weird. What OS?

Just tested on multiple distributions (Debian/Ubuntu/Fedora/Arch/Gentoo) and it works on all of them without including the four headers mentioned above.

SuperQ

comment created time in 2 months

PullRequestReviewEvent

Pull request review commentprometheus/snmp_exporter

Hacky workaround for net-snmp version detection

 package main #cgo CFLAGS: -I/usr/local/include #include <net-snmp/net-snmp-config.h> #include <net-snmp/mib_api.h>+#include <net-snmp/types.h>+#include <net-snmp/library/container.h>+#include <net-snmp/agent/snmp_agent.h>+#include <net-snmp/agent/snmp_vars.h>

These headers don't seem to be required (tested and works correctly without them on 5.7.3, 5.8, 5.9.1).

SuperQ

comment created time in 2 months

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentprometheus/snmp_exporter

Update generator for net-snmp 5.9

We need to determine the definition of tclist at compile time, but net-snmp only exposes its version as a string in the headers (e.g. #define PACKAGE_VERSION "5.9.1"), and there's no functionality available in the C preprocessor that could be used to implement version string comparisons.

I don't think supporting both variants is possible without adding a new utility that writes/chooses the correct C code for net_snmp.go (before compilation) depending on the installed net-snmp version.

tobbez

comment created time in 2 months

create barnchtobbez/snmp_exporter

branch : net-snmp-5.9

created branch time in 2 months

PR opened prometheus/snmp_exporter

Update generator for net-snmp 5.9

At some point in the past few months, CircleCI updated the circleci/golang:1.16 image from being based on Debian 10 (buster) to Debian 11 (bullseye). With this, net-snmp (libsnmp-dev) was updated from 5.7.3 to 5.9.

In net-snmp 5.9, the definition of tclist (copied into the generator's net_snmp.go) changed from

#define MAXTC   4096
struct tc {                     /* textual conventions */
    int             type;
    int             modid;
    char           *descriptor;
    char           *hint;
    struct enum_list *enums;
    struct range_list *ranges;
    char           *description;
} tclist[MAXTC];

to

#define TC_INCR 100
struct tc {                     /* textual conventions */
    int             type;
    int             modid;
    char           *descriptor;
    char           *hint;
    struct enum_list *enums;
    struct range_list *ranges;
    char           *description;
} *tclist;
int tc_alloc;

The mismatch between the definitions used by net-snmp and snmp_exporter caused the removal of all fixed_size fields in the generated snmp.yml, which in turn caused CI runs for recent PRs to fail (some examples of such PRs are 702, 700, 681).

This commit adapts net_snmp.go to the new definition of tclist.

+4 -4

0 comment

1 changed file

pr created time in 2 months

pull request commentprometheus/snmp_exporter

Support equipment responding from different source address

The CI failure seems to be unrelated to the changes in this PR.

tobbez

comment created time in 2 months

issue commentprometheus/snmp_exporter

Support equipment responding from different source address

In my limited experience it is indeed only specific (groups of) devices, so adding this to the module configuration would make sense (so that's what the PR does).

It would of course be convenient if this behavior was eventually made default (no need for a custom snmp.yml; devices like these "just working" if they work with snmpwalk), but as you say that'd need further consideration (which can be left for the future for now).

tobbez

comment created time in 2 months

create barnchtobbez/snmp_exporter

branch : different-source-addr

created branch time in 2 months

fork tobbez/snmp_exporter

SNMP Exporter for Prometheus

fork in 2 months

issue commenttobbez/deluge_exporter

Torrent info date added

It should be possible to add, but I will not implement it personally.

A PR adding a 'added date' metric would be accepted.

rjdodd00

comment created time in 2 months

create barnchtobbez/prometheus

branch : 2.25.0-changelog-entry

created branch time in 2 months

more