summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
Diffstat
-rw-r--r--.gitignore1
-rw-r--r--issues/gn-guile/rendering-images-within-markdown-documents.gmi22
-rw-r--r--issues/gn-guile/rework-hard-dependence-on-github.gmi21
-rw-r--r--issues/production-container-mechanical-rob-failure.gmi224
-rw-r--r--issues/systems/penguin2-raid5.gmi61
-rw-r--r--issues/systems/tux04-production.gmi275
-rw-r--r--tasks/alexm.gmi29
-rw-r--r--tasks/bonfacem.gmi49
-rw-r--r--tasks/felixl.gmi28
-rw-r--r--tasks/fredm.gmi16
-rw-r--r--tasks/pjotrp.gmi56
-rw-r--r--tasks/programmer-team/meetings.gmi82
-rw-r--r--tasks/zachs.gmi7
-rw-r--r--topics/ai/aider.gmi6
-rw-r--r--topics/ai/ontogpt.gmi7
-rw-r--r--topics/database/mariadb-database-architecture.gmi66
-rw-r--r--topics/deploy/installation.gmi2
-rw-r--r--topics/genenetwork-releases.gmi77
-rw-r--r--topics/systems/backup-drops.gmi21
-rw-r--r--topics/systems/backups-with-borg.gmi202
-rw-r--r--topics/systems/ci-cd.gmi48
-rw-r--r--topics/systems/screenshot-github-webhook.pngbin0 -> 177112 bytes
22 files changed, 1229 insertions, 71 deletions
diff --git a/.gitignore b/.gitignore
index 329cfdc..8a5b167 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@
index.gmi
tracker.gmi
.aider*
+.tissue/**/*
diff --git a/issues/gn-guile/rendering-images-within-markdown-documents.gmi b/issues/gn-guile/rendering-images-within-markdown-documents.gmi
new file mode 100644
index 0000000..fe3ed39
--- /dev/null
+++ b/issues/gn-guile/rendering-images-within-markdown-documents.gmi
@@ -0,0 +1,22 @@
+# Rendering Images Linked in Markdown Documents
+
+## Tags
+
+* status: open
+* priority: high
+* type: bug
+* assigned: alexm, bonfacem, fredm
+* keywords: gn-guile, images, markdown
+
+## Description
+
+Rendering images linked within markdown documents does not work as expected — we cannot render images if they have a relative path.
+As an example see the commit below:
+=> https://github.com/genenetwork/gn-docs/commit/783e7d20368e370fb497974f843f985b51606d00
+
+In that commit, we are forced to use the full github uri to get the images to load correctly when rendered via gn-guile. This, has two unfortunate consequences:
+
+* It makes editing more difficult, since the user has to remember to find and use the full github URL for their images.
+* It ties the data and code to github
+
+This needs to be fixed, such that any and all paths relative to the markdown file are resolved at render time automatically.
diff --git a/issues/gn-guile/rework-hard-dependence-on-github.gmi b/issues/gn-guile/rework-hard-dependence-on-github.gmi
new file mode 100644
index 0000000..751e9fe
--- /dev/null
+++ b/issues/gn-guile/rework-hard-dependence-on-github.gmi
@@ -0,0 +1,21 @@
+# Rework Hard Dependence on Github
+
+## Tags
+
+* status: open
+* priority: medium
+* type: bug
+* assigned: alexm
+* assigned: bonfacem
+* assigned: fredm
+* keywords: gn-guile, github
+
+## Description
+
+Currently, we have a hard-dependence on Github for our source repository — you can see this in lines 31, 41, 55 and 59 of the code linked below:
+
+=> https://git.genenetwork.org/gn-guile/tree/web/view/markdown.scm?id=0ebf6926db0c69e4c444a6f95907e0971ae9bf40
+
+The most likely reason is that the "edit online" functionality might not exist in a lot of other popular source forges.
+
+This is rendered moot, however, since we do provide a means to edit the data on Genenetwork itself. We might as well get rid of this option, and only allow the "edit online" feature on Genenetwork and stop relying on its presence in the forges we use.
diff --git a/issues/production-container-mechanical-rob-failure.gmi b/issues/production-container-mechanical-rob-failure.gmi
new file mode 100644
index 0000000..a32194e
--- /dev/null
+++ b/issues/production-container-mechanical-rob-failure.gmi
@@ -0,0 +1,224 @@
+# Production Container: `mechanical-rob` Failure
+
+## Tags
+
+* status: open
+* priority: high
+* type: bug
+* assigned: fredm
+* keywords: genenetwork, production, mechanical-rob
+
+## Description
+
+After deploying the latest commits to https://gn2-fred.genenetwork.org on 2025-02-19UTC-0600, with the following commits:
+
+* genenetwork2: 2a3df8cfba6b29dddbe40910c69283a1afbc8e51
+* genenetwork3: 99fd5070a84f37f91993f329f9cc8dd82a4b9339
+* gn-auth: 073395ff331042a5c686a46fa124f9cc6e10dd2f
+* gn-libs: 72a95f8ffa5401649f70978e863dd3f21900a611
+
+I had the (not so) bright idea to run the `mechanical-rob` tests against it before pushing it to production, proper. Here's where I ran into problems: some of the `mechanical-rob` tests failed, specifically, the correlation tests.
+
+Meanwhile, a run of the same tests against https://cd.genenetwork.org with the same commits was successful:
+
+=> https://ci.genenetwork.org/jobs/genenetwork2-mechanical-rob/1531 See this.
+
+This points to a possible problem with the setup of the production container, that leads to failures where none should be. This needs investigation and fixing.
+
+### Update 2025-02-20
+
+The MariaDB server is crashing. To reproduce:
+
+* Go to https://gn2-fred.genenetwork.org/show_trait?trait_id=1435464_at&dataset=HC_M2_0606_P
+* Click on "Calculate Correlations" to expand
+* Click "Compute"
+
+Observe that after a little while, the system fails with the following errors:
+
+* `MySQLdb.OperationalError: (2013, 'Lost connection to MySQL server during query')`
+* `MySQLdb.OperationalError: (2006, 'MySQL server has gone away')`
+
+I attempted updating the configuration for MariaDB, setting the `max_allowed_packet` to 16M and then 64M, but that did not resolve the problem.
+
+The log files indicate the following:
+
+```
+2025-02-20 7:46:07 0 [Note] Recovering after a crash using /var/lib/mysql/gn0-binary-log
+2025-02-20 7:46:07 0 [Note] Starting crash recovery...
+2025-02-20 7:46:07 0 [Note] Crash recovery finished.
+2025-02-20 7:46:07 0 [Note] Server socket created on IP: '0.0.0.0'.
+2025-02-20 7:46:07 0 [Warning] 'user' entry 'webqtlout@tux01' ignored in --skip-name-resolve mode.
+2025-02-20 7:46:07 0 [Warning] 'db' entry 'db_webqtl webqtlout@tux01' ignored in --skip-name-resolve mode.
+2025-02-20 7:46:07 0 [Note] Reading of all Master_info entries succeeded
+2025-02-20 7:46:07 0 [Note] Added new Master_info '' to hash table
+2025-02-20 7:46:07 0 [Note] /usr/sbin/mariadbd: ready for connections.
+Version: '10.5.23-MariaDB-0+deb11u1-log' socket: '/run/mysqld/mysqld.sock' port: 3306 Debian 11
+2025-02-20 7:46:07 4 [Warning] Access denied for user 'root'@'localhost' (using password: NO)
+2025-02-20 7:46:07 5 [Warning] Access denied for user 'root'@'localhost' (using password: NO)
+2025-02-20 7:46:07 0 [Note] InnoDB: Buffer pool(s) load completed at 250220 7:46:07
+250220 7:50:12 [ERROR] mysqld got signal 11 ;
+Sorry, we probably made a mistake, and this is a bug.
+
+Your assistance in bug reporting will enable us to fix this for the next release.
+To report this bug, see https://mariadb.com/kb/en/reporting-bugs
+
+We will try our best to scrape up some info that will hopefully help
+diagnose the problem, but since we have already crashed,
+something is definitely wrong and this may fail.
+
+Server version: 10.5.23-MariaDB-0+deb11u1-log source revision: 6cfd2ba397b0ca689d8ff1bdb9fc4a4dc516a5eb
+key_buffer_size=10485760
+read_buffer_size=131072
+max_used_connections=1
+max_threads=2050
+thread_count=1
+It is possible that mysqld could use up to
+key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 4523497 K bytes of memory
+Hope that's ok; if not, decrease some variables in the equation.
+
+Thread pointer: 0x7f599c000c58
+Attempting backtrace. You can use the following information to find out
+where mysqld died. If you see no messages after this, something went
+terribly wrong...
+stack_bottom = 0x7f6150282d78 thread_stack 0x49000
+/usr/sbin/mariadbd(my_print_stacktrace+0x2e)[0x55f43330c14e]
+/usr/sbin/mariadbd(handle_fatal_signal+0x475)[0x55f432e013b5]
+sigaction.c:0(__restore_rt)[0x7f615a1cb140]
+/usr/sbin/mariadbd(+0xcbffbe)[0x55f43314efbe]
+/usr/sbin/mariadbd(+0xd730ec)[0x55f4332020ec]
+/usr/sbin/mariadbd(+0xd1b36b)[0x55f4331aa36b]
+/usr/sbin/mariadbd(+0xd1cd8e)[0x55f4331abd8e]
+/usr/sbin/mariadbd(+0xc596f3)[0x55f4330e86f3]
+/usr/sbin/mariadbd(_ZN7handler18ha_index_next_sameEPhPKhj+0x2a5)[0x55f432e092b5]
+/usr/sbin/mariadbd(+0x7b54d1)[0x55f432c444d1]
+/usr/sbin/mariadbd(_Z10sub_selectP4JOINP13st_join_tableb+0x1f8)[0x55f432c37da8]
+/usr/sbin/mariadbd(_ZN10JOIN_CACHE24generate_full_extensionsEPh+0x134)[0x55f432d24224]
+/usr/sbin/mariadbd(_ZN10JOIN_CACHE21join_matching_recordsEb+0x206)[0x55f432d245d6]
+/usr/sbin/mariadbd(_ZN10JOIN_CACHE12join_recordsEb+0x1cf)[0x55f432d23eff]
+/usr/sbin/mariadbd(_Z16sub_select_cacheP4JOINP13st_join_tableb+0x8a)[0x55f432c382fa]
+/usr/sbin/mariadbd(_ZN4JOIN10exec_innerEv+0xd16)[0x55f432c63826]
+/usr/sbin/mariadbd(_ZN4JOIN4execEv+0x35)[0x55f432c63cc5]
+/usr/sbin/mariadbd(_Z12mysql_selectP3THDP10TABLE_LISTR4ListI4ItemEPS4_jP8st_orderS9_S7_S9_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x106)[0x55f432c61c26]
+/usr/sbin/mariadbd(_Z13handle_selectP3THDP3LEXP13select_resultm+0x138)[0x55f432c62698]
+/usr/sbin/mariadbd(+0x762121)[0x55f432bf1121]
+/usr/sbin/mariadbd(_Z21mysql_execute_commandP3THD+0x3d6c)[0x55f432bfdd1c]
+/usr/sbin/mariadbd(_Z11mysql_parseP3THDPcjP12Parser_statebb+0x20b)[0x55f432bff17b]
+/usr/sbin/mariadbd(_Z16dispatch_command19enum_server_commandP3THDPcjbb+0xdb5)[0x55f432c00f55]
+/usr/sbin/mariadbd(_Z10do_commandP3THD+0x120)[0x55f432c02da0]
+/usr/sbin/mariadbd(_Z24do_handle_one_connectionP7CONNECTb+0x2f2)[0x55f432cf8b32]
+/usr/sbin/mariadbd(handle_one_connection+0x5d)[0x55f432cf8dad]
+/usr/sbin/mariadbd(+0xbb4ceb)[0x55f433043ceb]
+nptl/pthread_create.c:478(start_thread)[0x7f615a1bfea7]
+x86_64/clone.S:97(__GI___clone)[0x7f6159dc6acf]
+
+Trying to get some variables.
+Some pointers may be invalid and cause the dump to abort.
+Query (0x7f599c012c50): SELECT ProbeSet.Name,ProbeSet.Chr,ProbeSet.Mb,
+ ProbeSet.Symbol,ProbeSetXRef.mean,
+ CONCAT_WS('; ', ProbeSet.description, ProbeSet.Probe_Target_Description) AS description,
+ ProbeSetXRef.additive,ProbeSetXRef.LRS,Geno.Chr, Geno.Mb
+ FROM ProbeSet INNER JOIN ProbeSetXRef
+ ON ProbeSet.Id=ProbeSetXRef.ProbeSetId
+ INNER JOIN Geno
+ ON ProbeSetXRef.Locus = Geno.Name
+ INNER JOIN Species
+ ON Geno.SpeciesId = Species.Id
+ WHERE ProbeSet.Name in ('1447591_x_at', '1422809_at', '1428917_at', '1438096_a_at', '1416474_at', '1453271_at', '1441725_at', '1452952_at', '1456774_at', '1438413_at', '1431110_at', '1453723_x_at', '1424124_at', '1448706_at', '1448762_at', '1428332_at', '1438389_x_at', '1455508_at', '1455805_x_at', '1433276_at', '1454989_at', '1427467_a_at', '1447448_s_at', '1438695_at', '1456795_at', '1454874_at', '1455189_at', '1448631_a_at', '1422697_s_at', '1423717_at', '1439484_at', '1419123_a_at', '1435286_at', '1439886_at', '1436348_at', '1437475_at', '1447667_x_at', '1421046_a_at', '1448296_x_at', '1460577_at', 'AFFX-GapdhMur/M32599_M_at', '1424393_s_at', '1426190_at', '1434749_at', '1455706_at', '1448584_at', '1434093_at', '1434461_at', '1419401_at', '1433957_at', '1419453_at', '1416500_at', '1439436_x_at', '1451413_at', '1455696_a_at', '1457190_at', '1455521_at', '1434842_s_at', '1442525_at', '1452331_s_at', '1428862_at', '1436463_at', '1438535_at', 'AFFX-GapdhMur/M32599_3_at', '1424012_at', '1440027_at', '1435846_x_at', '1443282_at', '1435567_at', '1450112_a_at', '1428251_at', '1429063_s_at', '1433781_a_at', '1436698_x_at', '1436175_at', '1435668_at', '1424683_at', '1442743_at', '1416944_a_at', '1437511_x_at', '1451254_at', '1423083_at', '1440158_x_at', '1424324_at', '1426382_at', '1420142_s_at', '1434553_at', '1428772_at', '1424094_at', '1435900_at', '1455322_at', '1453283_at', '1428551_at', '1453078_at', '1444602_at', '1443836_x_at', '1435590_at', '1434283_at', '1435240_at', '1434659_at', '1427032_at', '1455278_at', '1448104_at', '1421247_at', 'AFFX-MURINE_b1_at', '1460216_at', '1433969_at', '1419171_at', '1456699_s_at', '1456901_at', '1442139_at', '1421849_at', '1419824_a_at', '1460588_at', '1420131_s_at', '1446138_at', '1435829_at', '1434462_at', '1435059_at', '1415949_at', '1460624_at', '1426707_at', '1417250_at', '1434956_at', '1438018_at', '1454846_at', '1435298_at', '1442077_at', '1424074_at', '1428883_at', '1454149_a_at', '1423925_at', '1457060_at', '1433821_at', '1447923_at', '1460670_at', '1434468_at', '1454980_at', '1426913_at', '1456741_s_at', '1449278_at', '1443534_at', '1417941_at', '1433167_at', '1434401_at', '1456516_x_at', '1451360_at', 'AFFX-GapdhMur/M32599_5_at', '1417827_at', '1434161_at', '1448979_at', '1435797_at', '1419807_at', '1418330_at', '1426304_x_at', '1425492_at', '1437873_at', '1435734_x_at', '1420622_a_at', '1456019_at', '1449200_at', '1455314_at', '1428419_at', '1426349_s_at', '1426743_at', '1436073_at', '1452306_at', '1436735_at', '1439529_at', '1459347_at', '1429642_at', '1438930_s_at', '1437380_x_at', '1459861_s_at', '1424243_at', '1430503_at', '1434474_at', '1417962_s_at', '1440187_at', '1446809_at', '1436234_at', '1415906_at', 'AFFX-MURINE_B2_at', '1434836_at', '1426002_a_at', '1448111_at', '1452882_at', '1436597_at', '1455915_at', '1421846_at', '1428693_at', '1422624_at', '1423755_at', '1460367_at', '1433746_at', '1454872_at', '1429194_at', '1424652_at', '1440795_x_at', '1458690_at', '1434355_at', '1456324_at', '1457867_at', '1429698_at', '1423104_at', '1437585_x_at', '1437739_a_at', '1445605_s_at', '1436313_at', '1449738_s_at', '1437525_a_at', '1454937_at', '1429043_at', '1440091_at', '1422820_at', '1437456_x_at', '1427322_at', '1446649_at', '1433568_at', '1441114_at', '1456541_x_at', '1426985_s_at', '1454764_s_at', '1424071_s_at', '1429251_at', '1429155_at', '1433946_at', '1448771_a_at', '1458664_at', '1438320_s_at', '1449616_s_at', '1435445_at', '1433872_at', '1429273_at', '1420880_a_at', '1448645_at', '1449646_s_at', '1428341_at', '1431299_a_at', '1433427_at', '1418530_at', '1436247_at', '1454350_at', '1455860_at', '1417145_at', '1454952_s_at', '1435977_at', '1434807_s_at', '1428715_at', '1418117_at', '1447947_at', '1431781_at', '1428915_at', '1427197_at', '1427208_at', '1455460_at', '1423899_at', '1441944_s_at', '1455429_at', '1452266_at', '1454409_at', '1426384_a_at', '1428725_at', '1419181_at', '1454862_at', '1452907_at', '1433794_at', '1435492_at', '1424839_a_at', '1416214_at', '1449312_at', '1436678_at', '1426253_at', '1438859_x_at', '1448189_a_at', '1442557_at', '1446174_at', '1459718_x_at', '1437613_s_at', '1456509_at', '1455267_at', '1440480_at', '1417296_at', '1460050_x_at', '1433585_at', '1436771_x_at', '1424294_at', '1448648_at', '1417753_at', '1436139_at', '1425642_at', '1418553_at', '1415747_s_at', '1445984_at', '1440024_at', '1448720_at', '1429459_at', '1451459_at', '1428853_at', '1433856_at', '1426248_at', '1417765_a_at', '1439459_x_at', '1447023_at', '1426088_at', '1440825_s_at', '1417390_at', '1444744_at', '1435618_at', '1424635_at', '1443727_x_at', '1421096_at', '1427410_at', '1416860_s_at', '1442773_at', '1442030_at', '1452281_at', '1434774_at', '1416891_at', '1447915_x_at', '1429129_at', '1418850_at', '1416308_at', '1422858_at', '1447679_s_at', '1440903_at', '1417321_at', '1452342_at', '1453510_s_at', '1454923_at', '1454611_a_at', '1457532_at', '1438440_at', '1434232_a_at', '1455878_at', '1455571_x_at', '1436401_at', '1453289_at', '1457365_at', '1436708_x_at', '1434494_at', '1419588_at', '1433679_at', '1455159_at', '1428982_at', '1446510_at', '1434131_at', '1418066_at', '1435346_at', '1449415_at', '1455384_x_at', '1418817_at', '1442073_at', '1457265_at', '1447361_at', '1418039_at', '1428467_at', '1452224_at', '1417538_at', '1434529_x_at', '1442149_at', '1437379_x_at', '1416473_a_at', '1432750_at', '1428389_s_at', '1433823_at', '1451889_at', '1438178_x_at', '1441807_s_at', '1416799_at', '1420623_x_at', '1453245_at', '1434037_s_at', '1443012_at', '1443172_at', '1455321_at', '1438396_at', '1440823_x_at', '1436278_at', '1457543_at', '1452908_at', '1417483_at', '1418397_at', '1446589_at', '1450966_at', '1447877_x_at', '1446524_at', '1438592_at', '1455589_at', '1428629_at', '1429585_s_at', '1440020_at', '1417365_a_at', '1426442_at', '1427151_at', '1437377_a_at', '1433995_s_at', '1435464_at', '1417007_a_at', '1429690_at', '1427999_at', '1426819_at', '1454905_at', '1439516_at', '1434509_at', '1428707_at', '1416793_at', '1440822_x_at', '1437327_x_at', '1428682_at', '1435004_at', '1434238_at', '1417581_at', '1434699_at', '1455597_at', '1458613_at', '1456485_at', '1435122_x_at', '1452864_at', '1453122_at', '1435254_at', '1451221_at', '1460168_at', '1455336_at', '1427965_at', '1432576_at', '1455425_at', '1428762_at', '1455459_at', '1419317_x_at', '1434691_at', '1437950_at', '1426401_at', '1457261_at', '1433824_x_at', '1435235_at', '1437343_x_at', '1439964_at', '1444280_at', '1455434_a_at', '1424431_at', '1421519_a_at', '1428412_at', '1434010_at', '1419976_s_at', '1418887_a_at', '1428498_at', '1446883_at', '1435675_at', '1422599_s_at', '1457410_at', '1444437_at', '1421050_at', '1437885_at', '1459754_x_at', '1423807_a_at', '1435490_at', '1426760_at', '1449459_s_at', '1432098_a_at', '1437067_at', '1435574_at', '1433999_at', '1431289_at', '1428919_at', '1425678_a_at', '1434924_at', '1421640_a_at', '1440191_s_at', '1460082_at', '1449913_at', '1439830_at', '1425020_at', '1443790_x_at', '1436931_at', '1454214_a_at', '1455854_a_at', '1437061_at', '1436125_at', '1426385_x_at', '1431893_a_at', '1417140_a_at', '1435333_at', '1427907_at', '1434446_at', '1417594_at', '1426518_at', '1437345_a_at', '1420091_s_at', '1450058_at', '1435161_at', '1430348_at', '1455778_at', '1422653_at', '1447942_x_at', '1434843_at', '1454956_at', '1454998_at', '1427384_at', '1439828_at') AND
+ Species.Name = 'mouse' AND
+ ProbeSetXRef.ProbeSetFreezeId IN (
+ SELECT ProbeSetFreeze.Id
+ FROM ProbeSetFreeze WHERE ProbeSetFreeze.Name = 'HC_M2_0606_P')
+
+Connection ID (thread ID): 41
+Status: NOT_KILLED
+
+Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=on,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on,condition_pushdown_for_subquery=on,rowid_filter=on,condition_pushdown_from_having=on,not_null_range_scan=off
+
+The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mariadbd/ contains
+information that should help you find out what is causing the crash.
+Writing a core file...
+Working directory at /export/mysql/var/lib/mysql
+Resource Limits:
+Limit Soft Limit Hard Limit Units
+Max cpu time unlimited unlimited seconds
+Max file size unlimited unlimited bytes
+Max data size unlimited unlimited bytes
+Max stack size 8388608 unlimited bytes
+Max core file size 0 unlimited bytes
+Max resident set unlimited unlimited bytes
+Max processes 3094157 3094157 processes
+Max open files 64000 64000 files
+Max locked memory 65536 65536 bytes
+Max address space unlimited unlimited bytes
+Max file locks unlimited unlimited locks
+Max pending signals 3094157 3094157 signals
+Max msgqueue size 819200 819200 bytes
+Max nice priority 0 0
+Max realtime priority 0 0
+Max realtime timeout unlimited unlimited us
+Core pattern: core
+
+Kernel version: Linux version 5.10.0-22-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.178-3 (2023-04-22)
+
+2025-02-20 7:50:17 0 [Note] Starting MariaDB 10.5.23-MariaDB-0+deb11u1-log source revision 6cfd2ba397b0ca689d8ff1bdb9fc4a4dc516a5eb as process 3086167
+2025-02-20 7:50:17 0 [Note] InnoDB: !!! innodb_force_recovery is set to 1 !!!
+2025-02-20 7:50:17 0 [Note] InnoDB: Uses event mutexes
+2025-02-20 7:50:17 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
+2025-02-20 7:50:17 0 [Note] InnoDB: Number of pools: 1
+2025-02-20 7:50:17 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
+2025-02-20 7:50:17 0 [Note] InnoDB: Using Linux native AIO
+2025-02-20 7:50:17 0 [Note] InnoDB: Initializing buffer pool, total size = 17179869184, chunk size = 134217728
+2025-02-20 7:50:17 0 [Note] InnoDB: Completed initialization of buffer pool
+2025-02-20 7:50:17 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=1537379110991,1537379110991
+2025-02-20 7:50:17 0 [Note] InnoDB: Last binlog file '/var/lib/mysql/gn0-binary-log.000134', position 82843148
+2025-02-20 7:50:17 0 [Note] InnoDB: 128 rollback segments are active.
+2025-02-20 7:50:17 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
+2025-02-20 7:50:17 0 [Note] InnoDB: Creating shared tablespace for temporary tables
+2025-02-20 7:50:17 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
+2025-02-20 7:50:17 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
+2025-02-20 7:50:17 0 [Note] InnoDB: 10.5.23 started; log sequence number 1537379111003; transaction id 3459549902
+2025-02-20 7:50:17 0 [Note] Plugin 'FEEDBACK' is disabled.
+2025-02-20 7:50:17 0 [Note] InnoDB: Loading buffer pool(s) from /export/mysql/var/lib/mysql/ib_buffer_pool
+2025-02-20 7:50:17 0 [Note] Loaded 'locales.so' with offset 0x7f9551bc0000
+2025-02-20 7:50:17 0 [Note] Recovering after a crash using /var/lib/mysql/gn0-binary-log
+2025-02-20 7:50:17 0 [Note] Starting crash recovery...
+2025-02-20 7:50:17 0 [Note] Crash recovery finished.
+2025-02-20 7:50:17 0 [Note] Server socket created on IP: '0.0.0.0'.
+2025-02-20 7:50:17 0 [Warning] 'user' entry 'webqtlout@tux01' ignored in --skip-name-resolve mode.
+2025-02-20 7:50:17 0 [Warning] 'db' entry 'db_webqtl webqtlout@tux01' ignored in --skip-name-resolve mode.
+2025-02-20 7:50:17 0 [Note] Reading of all Master_info entries succeeded
+2025-02-20 7:50:17 0 [Note] Added new Master_info '' to hash table
+2025-02-20 7:50:17 0 [Note] /usr/sbin/mariadbd: ready for connections.
+Version: '10.5.23-MariaDB-0+deb11u1-log' socket: '/run/mysqld/mysqld.sock' port: 3306 Debian 11
+2025-02-20 7:50:17 4 [Warning] Access denied for user 'root'@'localhost' (using password: NO)
+2025-02-20 7:50:17 5 [Warning] Access denied for user 'root'@'localhost' (using password: NO)
+2025-02-20 7:50:17 0 [Note] InnoDB: Buffer pool(s) load completed at 250220 7:50:17
+```
+
+A possible issue is the use of the environment variable SQL_URI at this point:
+
+=> https://github.com/genenetwork/genenetwork2/blob/testing/gn2/wqflask/correlation/rust_correlation.py#L34
+
+which is requested
+
+=> https://github.com/genenetwork/genenetwork2/blob/testing/gn2/wqflask/correlation/rust_correlation.py#L7 from here.
+
+I tried setting an environment variable "SQL_URI" with the same value as the config and rebuilt the container. That did not fix the problem.
+
+Running the query directly in the default mysql client also fails with:
+
+```
+ERROR 2013 (HY000): Lost connection to MySQL server during query
+```
+
+Huh, so this was not a code problem.
+
+Configured database to allow upgrade of tables if necessary and restarted mariadbd.
+
+The problem still persists.
+
+Note Pjotr: this is likely a mariadb bug with 10.5.23, the most recent mariadbd we use (both tux01 and tux02 are older). The dump shows it balks on creating a new thread: pthread_create.c:478. Looks similar to https://jira.mariadb.org/browse/MDEV-32262
+
+10.5, 10.6, 10.11 are affected. so running correlations on production crashes mysqld? I am not trying for obvious reasons ;) the threading issues of mariadb look scary - I wonder how deep it goes.
+
+We'll test for a different version of mariadb combining a Debian update because Debian on tux04 is broken.
diff --git a/issues/systems/penguin2-raid5.gmi b/issues/systems/penguin2-raid5.gmi
new file mode 100644
index 0000000..f03075d
--- /dev/null
+++ b/issues/systems/penguin2-raid5.gmi
@@ -0,0 +1,61 @@
+# Penguin2 RAID 5
+
+# Tags
+
+* assigned: @fredm, @pjotrp
+* status: in progress
+
+# Description
+
+The current RAID contains 3 disks:
+
+```
+root@penguin2:~# cat /proc/mdstat
+md0 : active raid5 sdb1[1] sda1[0] sdg1[4]
+/dev/md0 33T 27T 4.2T 87% /export
+```
+
+using /dev/sda,sdb,sdg
+
+The current root and swap is on
+
+```
+# root
+/dev/sdd1 393G 121G 252G 33% /
+# swap
+/dev/sdd5 partition 976M 76.5M -2
+```
+
+We can therefore add four new disks in slots /dev/sdc,sde,sdf,sdh
+
+penguin2 has no out-of-band and no serial connector right now. That means any work needs to be done on the terminal.
+
+Boot loader menu:
+
+```
+menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-7ff268df-cb90-4cbc-9d76-7fd6677b4964' {
+ load_video
+ insmod gzio
+ if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
+ insmod part_msdos
+ insmod ext2
+ set root='hd2,msdos1'
+ if [ x$feature_platform_search_hint = xy ]; then
+ search --no-floppy --fs-uuid --set=root --hint-bios=hd2,msdos1 --hint-efi=hd2,msdos1 --hint-baremetal=ahci2,msdos1 7ff268df-cb90-4cbc-9d76-7fd6677b4964
+ else
+ search --no-floppy --fs-uuid --set=root 7ff268df-cb90-4cbc-9d76-7fd6677b4964
+ fi
+ echo 'Loading Linux 5.10.0-18-amd64 ...'
+ linux /boot/vmlinuz-5.10.0-18-amd64 root=UUID=7ff268df-cb90-4cbc-9d76-7fd6677b4964 ro quiet
+ echo 'Loading initial ramdisk ...'
+ initrd /boot/initrd.img-5.10.0-18-amd64
+}
+```
+
+Added to sdd MBR
+
+```
+root@penguin2:~# grub-install /dev/sdd
+Installing for i386-pc platform.
+Installation finished. No error reported.
+```
diff --git a/issues/systems/tux04-production.gmi b/issues/systems/tux04-production.gmi
new file mode 100644
index 0000000..01e1638
--- /dev/null
+++ b/issues/systems/tux04-production.gmi
@@ -0,0 +1,275 @@
+# Production on tux04
+
+Lately we have been running production on tux04. Unfortunately Debian got broken and I don't see a way to fix it (something with python versions that break apt!). Also mariadb is giving problems:
+
+=> issues/production-container-mechanical-rob-failure.gmi
+
+and that is alarming. We might as well try an upgrade. I created a new partition on /dev/sda4 using debootstrap.
+
+Luckily not too much is running on this machine and if we mount things again, most should work.
+
+# Tasks
+
+* [X] cleanly shut down mariadb
+* [X] reboot into new partition /dev/sda4
+* [X] git in /etc
+* [X] make sure serial boot works (/etc/default/grub)
+* [X] fix groups and users
+* [X] get guix going
+* [X] get mariadb going
+* [X] fire up GN2 service
+* [X] fire up SPARQL service
+* [X] sheepdog
+* [ ] fix CRON jobs and backups
+* [ ] test full reboots
+
+
+# Boot in new partition
+
+```
+blkid /dev/sda4
+/dev/sda4: UUID="4aca24fe-3ece-485c-b04b-e2451e226bf7" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="2e3d569f-6024-46ea-8ef6-15b26725f811"
+```
+
+After debootstrap there are two things to take care of: the /dev directory and grub. For good measure
+I also capture some state
+
+```
+cd ~
+ps xau > cron.log
+systemctl > systemctl.txt
+cp /etc/network/interfaces .
+cp /boot/grub/grub.cfg .
+```
+
+we should still have access to the old root partition, so I don't need to capture everything.
+
+## /dev
+
+I ran MAKEDEV and that may not be needed with udev.
+
+## grub
+
+We need to tell grub to boot into the new partition. The old root is on
+UUID=8e874576-a167-4fa1-948f-2031e8c3809f /dev/sda2.
+
+Next I ran
+
+```
+tux04:~$ update-grub2 /dev/sda
+Generating grub configuration file ...
+Found linux image: /boot/vmlinuz-5.10.0-32-amd64
+Found initrd image: /boot/initrd.img-5.10.0-32-amd64
+Found linux image: /boot/vmlinuz-5.10.0-22-amd64
+Found initrd image: /boot/initrd.img-5.10.0-22-amd64
+Warning: os-prober will be executed to detect other bootable partitions.
+Its output will be used to detect bootable binaries on them and create new boot entries.
+Found Debian GNU/Linux 12 (bookworm) on /dev/sda4
+Found Windows Boot Manager on /dev/sdd1@/efi/Microsoft/Boot/bootmgfw.efi
+Found Debian GNU/Linux 11 (bullseye) on /dev/sdf2
+```
+
+Very good. Do a diff on grub.cfg and you see it even picked up the serial configuration. It only shows it added menu entries for the new boot. Very nice.
+
+At this point I feel safe to boot as we should be able to get back into the old partition.
+
+# /etc/fstab
+
+The old fstab looked like
+
+```
+UUID=8e874576-a167-4fa1-948f-2031e8c3809f / ext4 errors=remount-ro 0 1
+# /boot/efi was on /dev/sdc1 during installation
+UUID=998E-68AF /boot/efi vfat umask=0077 0 1
+# swap was on /dev/sdc3 during installation
+UUID=cbfcd84e-73f8-4cec-98ee-40cad404735f none swap sw 0 0
+UUID="783e3bd6-5610-47be-be82-ac92fdd8c8b8" /export2 ext4 auto 0 2
+UUID="9e6a9d88-66e7-4a2e-a12c-f80705c16f4f" /export ext4 auto 0 2
+UUID="f006dd4a-2365-454d-a3a2-9a42518d6286" /export3 auto auto 0 2
+/export2/gnu /gnu none defaults,bind 0 0
+# /dev/sdd1: PARTLABEL="bulk" PARTUUID="b1a820fe-cb1f-425e-b984-914ee648097e"
+# /dev/sdb4 /export ext4 auto 0 2
+# /dev/sdd1 /export2 ext4 auto 0 2
+```
+
+# reboot
+
+Next we are going to reboot, and we need a serial connector to the Dell out-of-band using racadm:
+
+```
+ssh IP
+console com2
+racadm getsel
+racadm serveraction powercycle
+racadm serveraction powerstatus
+
+```
+
+Main trick it so hit ESC, wait 2 sec and 2 when you want the bios boot menu. Ctrl-\ to escape console. Otherwise ESC (wait) ! to get to the boot menu.
+
+# First boot
+
+It still boots by default into the old root. That gave an error:
+
+[FAILED] Failed to start File Syste…a-2365-454d-a3a2-9a42518d6286
+
+This is /export3. We can fix that later.
+
+When I booted into the proper partition the console clapped out. Also the racadm password did not work on tmux -- I had to switch to a standard console to log in again. Not sure why that is, but next I got:
+
+```
+Give root password for maintenance
+(or press Control-D to continue):
+```
+
+and giving the root password I was in maintenance mode on the correct partition!
+
+To rerun grup I had to add `GRUB_DISABLE_OS_PROBER=false`.
+
+Once booting up it is a matter of mounting partitions and tick the check boxes above.
+
+The following contained errors:
+
+```
+/dev/sdd1 3.6T 1.8T 1.7T 52% /export2
+```
+
+# Guix
+
+Getting guix going is a bit tricky because we want to keep the store!
+
+```
+cp -vau /mnt/old-root/var/guix/ /var/
+cp -vau /mnt/old-root/usr/local/guix-profiles /usr/local/
+cp -vau /mnt/old-root/usr/local/bin/* /usr/local/bin/
+cp -vau /mnt/old-root/etc/systemd/system/guix-daemon.service* /etc/systemd/system/
+cp -vau /mnt/old-root/etc/systemd/system/gnu-store.mount* /etc/systemd/system/
+```
+
+Also had to add guixbuild users and group by hand.
+
+# nginx
+
+We use the streaming facility. Check that
+
+```
+nginx -V
+```
+
+lists --with-stream=static, see
+
+=> https://serverfault.com/questions/858067/unknown-directive-stream-in-etc-nginx-nginx-conf86/858074#858074
+
+and load at the start of nginx.conf:
+
+```
+load_module /usr/lib/nginx/modules/ngx_stream_module.so;
+```
+
+and
+
+```
+nginx -t
+```
+
+passes
+
+Now the container responds to the browser with `Internal Server Error`.
+
+# container web server
+
+Visit the container with something like
+
+```
+nsenter -at 2838 /run/current-system/profile/bin/bash --login
+```
+
+The nginx log in the container has many
+
+```
+2025/02/22 17:23:48 [error] 136#0: *166916 connect() failed (111: Connection refused) while connecting to upstream, client: 127.0.0.1, server: genenetwork.org, request: "GET /gn3/gene/aliases/st%2029:1;o;s HTTP/1.1", upstream: "http://127.0.0.1:9800/gene/aliases/st%2029:1;o;s", host: "genenetwork.org"
+```
+
+that is interesting. Acme/https is working because GN2 is working:
+
+```
+curl https://genenetwork.org/api3/version
+"1.0"
+```
+
+Looking at the logs it appears it is a redis problem first for GN2.
+
+Fred builds the container with `/home/fredm/opt/guix-production/bin/guix`. Machines are defined in
+
+```
+fredm@tux04:/export3/local/home/fredm/gn-machines
+```
+
+The shared dir for redis is at
+
+--share=/export2/guix-containers/genenetwork/var/lib/redis=/var/lib/redis
+
+with
+
+```
+root@genenetwork-production /var# ls lib/redis/ -l
+-rw-r--r-- 1 redis redis 629328484 Feb 22 17:25 dump.rdb
+```
+
+In production.scm it is defined as
+
+```
+(service redis-service-type
+ (redis-configuration
+ (bind "127.0.0.1")
+ (port 6379)
+ (working-directory "/var/lib/redis")))
+```
+
+The defaults are the same as the definition of redis-service-type (in guix). Not sure why we are duplicating.
+
+After starting redis by hand I get another error `500 DatabaseError: The following exception was raised while attempting to access http://auth.genenetwork.org/auth/data/authorisation: database disk image is malformed`. The problem is it created
+a DB in the wrong place. Alright, the logs in the container say:
+
+```
+Feb 23 14:04:31 genenetwork-production shepherd[1]: [redis-server] 3977:C 23 Feb 2025 14:04:31.040 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
+Feb 23 14:04:31 genenetwork-production shepherd[1]: [redis-server] 3977:C 23 Feb 2025 14:04:31.040 # Redis version=7.0.12, bits=64, commit=00000000, modified=0, pid=3977, just started
+Feb 23 14:04:31 genenetwork-production shepherd[1]: [redis-server] 3977:C 23 Feb 2025 14:04:31.040 # Configuration loaded
+Feb 23 14:04:31 genenetwork-production shepherd[1]: [redis-server] 3977:M 23 Feb 2025 14:04:31.041 * Increased maximum number of open files to 10032 (it was originally set to 1024).
+Feb 23 14:04:31 genenetwork-production shepherd[1]: [redis-server] 3977:M 23 Feb 2025 14:04:31.041 * monotonic clock: POSIX clock_gettime
+Feb 23 14:04:31 genenetwork-production shepherd[1]: [redis-server] 3977:M 23 Feb 2025 14:04:31.041 * Running mode=standalone, port=6379.
+Feb 23 14:04:31 genenetwork-production shepherd[1]: [redis-server] 3977:M 23 Feb 2025 14:04:31.042 # Server initialized
+Feb 23 14:04:31 genenetwork-production shepherd[1]: [redis-server] 3977:M 23 Feb 2025 14:04:31.042 # WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
+Feb 23 14:04:31 genenetwork-production shepherd[1]: [redis-server] 3977:M 23 Feb 2025 14:04:31.042 # Wrong signature trying to load DB from file
+Feb 23 14:04:31 genenetwork-production shepherd[1]: [redis-server] 3977:M 23 Feb 2025 14:04:31.042 # Fatal error loading the DB: Invalid argument. Exiting.
+Feb 23 14:04:31 genenetwork-production shepherd[1]: Service redis (PID 3977) exited with 1.
+```
+
+This is caused by a newer version of redis. This is odd because we are using the same version from the container?!
+
+Actually it turned out the redis DB was corrupted on the SSD! Same for some other databases (ugh).
+
+Fred copied all data to an enterprise level storage, and we rolled back to some older DBs, so hopefully we'll be OK for now.
+
+# Reinstating backups
+
+In the next step we need to restore backups as described in
+
+=> /topics/systems/backups-with-borg
+
+I already created an ibackup user. Next we test the backup script for mariadb.
+
+One important step is to check the database:
+
+```
+/usr/bin/mariadb-check -c -u user -p* db_webqtl
+```
+
+A successful mariadb backup consists of multiple steps
+
+```
+2025-02-27 11:48:28 +0000 (ibackup@tux04) SUCCESS 0 <32m43s> mariabackup-dump
+2025-02-27 11:48:29 +0000 (ibackup@tux04) SUCCESS 0 <00m00s> mariabackup-make-consistent
+2025-02-27 12:16:37 +0000 (ibackup@tux04) SUCCESS 0 <28m08s> borg-tux04-sql-backup
+2025-02-27 12:16:46 +0000 (ibackup@tux04) SUCCESS 0 <00m07s> drop-rsync-balg01
+```
diff --git a/tasks/alexm.gmi b/tasks/alexm.gmi
index 88d3927..b3031d3 100644
--- a/tasks/alexm.gmi
+++ b/tasks/alexm.gmi
@@ -1,4 +1,4 @@
-# Tasks for Fred
+# Tasks for Alex
## Description
@@ -16,11 +16,24 @@ You can refine the search by constraining the checks some more, e.g. to get high
# Tasks
-* [ ] Make GNQA reliable (with @fahamu)
-* [ ] Improve UX for GNQA (with @shelbys)
-* [ ] GNQA add abstracts pubmed (with @shelbys)
-=> ../issues/fetch-pubmed-references-to-gnqa
+## This week
+
+* [X] Rqtl2 - BXD output work on CD
+* [X] Rqtl2 - ITP output - 3K individuals - family file
+* [ ] Minor refactorings
+* [ ] Accelerate Xapian functionality
+* [ ] Start application - Pwani
+* [+] Create terminal output for external processes on *PRODUCTION* (Rqtl1, Rqtl2, GEMMA, pair-scan are done --- WGCNA as a pilot, with @bonfacem and @pjotrp)
+
+## Next week(s)
-* [ ] Edit markdown/gemtext pages through web UI (with @bonfacem)
-* [ ] GNQA add GN metadata with @bonfacem
-* [ ] Create terminal output for external processes (WGCNA as a pilot, with @bonfacem and @pjotrp)
+* [+] Create terminal output for external processes (Rqtl1, Rqtl2, pair-scan are done --- WGCNA as a pilot, with @bonfacem and @pjotrp)
+* [ ] GNQA says there are no results, but has them
+
+## Done
+
+* [X] Make GNQA reliable (with @fahamu)
+* [X] Improve UX for GNQA (with @shelbys) -- Adrian wants to use our AI UX for their setup
+* [X] GNQA add abstracts pubmed (with @shelbys)
+=> ../issues/fetch-pubmed-references-to-gnqa
+* [X] Edit markdown/gemtext pages through web UI (with @bonfacem)
diff --git a/tasks/bonfacem.gmi b/tasks/bonfacem.gmi
index 52f4027..7514e5b 100644
--- a/tasks/bonfacem.gmi
+++ b/tasks/bonfacem.gmi
@@ -8,9 +8,44 @@
## Tasks
-* [X] Indexing generif data / Improve Local Search
-* [ ] Add hashes to RDF metadata
-* [-] Brain Data (To be spec'ed further)
+### This week
+
+* [ ] Describe Generif/wikidata access for Rob in an email with test account on CD
+* 1. Send email to Rob
+* 2. Work on production
+* [ ] Migrate fahamuai RAG to VPS and switch tokens to GGI OpenAI account
+* 1. Running AI server using (our) VPS and our tokens
+* 2. Read the code base
+* 3. Try ingestion and prompt (REST API)
+* 4. Backup state from production Elixir
+* 5. Assess porting it to Guix (don't do any work) - minimum version Elixir
+* [ ] xapian search, add dataset size keys, as well as GN accession id, trait id, and date/year
+* - Improve xapian markdown docs to show all used fields/keys with examples
+* - genewiki search (link in table? check with Rob)
+* - base line with GN1 search - add tests
+* - Fix missing search term for sh* - both menu search and global search
+* - Use GN1 as a benchmark for search results (mechanical Rob?)
+* - Xapian ranges for markers
+* [ ] With Alex get rqtl2 demo going in CD (for BXD)
+
+### Later
+
+* [ ] Sample/individual/strain/genometype counts for PublishData only - ProbeSetData? https://github.com/genenetwork/genenetwork2/blob/testing/scripts/sample_count.py - mirror in RDF and use global search
+* - search for all traits that have more than X samples
+* [+] Use aider - give a presentation in the coming weeks
+* [ ] Add case attributes to RDF and share with Felix (depends on @felixl)
+
+### Even later
+
+* [ ] Rest API for precompute output (mapping with GEMMA)
+* [ ] GNQA add GN metadata (to RAG)
+* - Focus on RIF
+* - triple -> plain text
+* - bob :fatherof nancy -> Bob is the father of Nancy.
+
+## Later
+
+* [ ] AI improvements
### On going tasks
@@ -34,3 +69,11 @@ Should something in one of these closed issues be amiss, we can always and shoul
Currently closed issues are:
=> https://issues.genenetwork.org/search?type=closed-issue&query=assigned%3ABonfaceKilz%20AND%20type%3Aissue%20AND%20is%3Aclosed Closed Issues
+
+* [X] Indexing generif data / Improve Local Search
+* [X] lmdb publishdata output and share with Pjotr and Johannes
+
+## Done
+
+* [X] Add lmdb output hashes with index and export LMDB_DATA_DIRECTORY
+* [X] Share small database with @pjotrp and @felixl
diff --git a/tasks/felixl.gmi b/tasks/felixl.gmi
index 209e8c9..b39ff7b 100644
--- a/tasks/felixl.gmi
+++ b/tasks/felixl.gmi
@@ -1,4 +1,4 @@
-# Tasks for Munyoki
+# Tasks for Felix
## Tags
@@ -6,12 +6,34 @@
* assigned: felixl
* status: in progress
-## October
+## Tasks
+#### This week
+
+* [ ] Finalize the slide deck - so it can be read on its own
+* [ ] Analyse and discuss BXD case attributes with Rob --- both group level and dataset level
+* [ ] Sane representation of case attributes in RDF with @bonfacem
+* [X] Present C.elegans protocol and example mappings with GEMMA/Rqtl
+* [ ] Uploader - setting up code with @fredm
+* - [X] run small database mysql locally
+* - [X] aider with Sonnet + code fixes
+* - [ ] document - add to code base - merge with Fred's tree - share changes with Pjotr & team
+* [ ] Review paper: one-liners for @pjotrp - why is this important for GN and/or thesis
+* - [ ] list of relevant papers with one-liners - the WHY
+* [ ] Sort @alexm application with Pwani = this week
+
+### Later weeks
+
+* [ ] Review paper on genotyping
+* [ ] HS Rat
+* [ ] Prepare others for C.elegans
* [ ] Upload Arabidopsis dataset
* [ ] Upload Medaka dataset
-## Tasks
+### Done
+
+
+
### On going tasks
=> https://issues.genenetwork.org/search?query=assigned%3Afelixl+AND+is%3Aopen&type=open-issue All in-progress tasks
diff --git a/tasks/fredm.gmi b/tasks/fredm.gmi
index 5e7e71d..1cd3125 100644
--- a/tasks/fredm.gmi
+++ b/tasks/fredm.gmi
@@ -1,5 +1,21 @@
# Tasks for Fred
+# Tags
+
+* kanban: fredm
+* assigned: @fredm
+* status: in progress
+
+# Tasks
+
+* [ ] Add drives to Penguin2, see issues/systems/penguin2-raid5
+* [X] Move production files from sdc to sde
+* [ ] Fix password weakness
+* [ ] Fix gn-docs and editing, e.g. facilities page by gn-guile in container
+* [ ] Unifiy container dirs
+* [ ] Fix wikidata gene aliases (see mapping page) with @pjotrp
+* [ ] Public SPARQL container?
+
## Description
These are the tasks and issues to be handled by Fred.
diff --git a/tasks/pjotrp.gmi b/tasks/pjotrp.gmi
index b284c46..e5e25fe 100644
--- a/tasks/pjotrp.gmi
+++ b/tasks/pjotrp.gmi
@@ -6,24 +6,41 @@
* assigned: pjotrp
* status: in progress
-# Notes
-
-The tasks here should probably be broken out into appropriately tagged issues, where they have not - they can be found and filtered out with tissue (formerly gnbug).
+# Current
-=> https://issues.genenetwork.org
+## 1U01HG013760
-Generally work applies to NIH/R073237482 and other grants.
+* Prefix-Free Parsing Compressed Suffix Tree (PFP) for tokenization
+* Mempig
-# Current
+* [+] create backup server with @fredm
+* [+] Moni builds 1U01HG013760
+* [+] test framework wfmash - vertebrate tree and HPC compute?
+* [ ] gbam - data compression with Nick and Hasithak
+* [ ] accelerate wfmash with @santiago and team
+* [ ] package wfmash and Rust wfa2-lib
+* [ ] add Ceph for distributed network storage 1U01HG013760
+* [ ] Work on pangenome genotyping 1U01HG013760
+* [ ] update freebayes into Debian (version #)
+* - [ ] static build and prepare for conda
+* [ ] update vcflib into Debian (version #)
+* - [ ] static build and prepare for conda
+* [ ] pangenome as a 1st class input for GEMMA
+* kilifish pangenome with Paul and Dario
+* RAG with Shelby and Bonz
## Systems
+* [ ] Backup production databases on Tux04
+* - [ ] Dump redis
+* - [ ] Dump sqlite
+* - [ ] Dump mariadb
* [ ] make sure production is up to scratch (see stable below)
-* [ ] backup tux04
-* [ ] add Ceph for distributed network storage 1U01HG013760
+* [ ] synchronize git repos for public, CD, fallback and production using sheepdog and document
* [ ] drop tux02 backups on balg01
-* [ ] drop backups NL
+* [ ] drop backups in NL
* [ ] reintroduce borg-borg
+* [X] Small database public
## Ongoing tasks (current/urgent)
@@ -33,8 +50,6 @@ Generally work applies to NIH/R073237482 and other grants.
* [ ] Check email setup tux04
* [+] Julia as part of GN3 deployment
=> /topics/deploy/julia.gmi
-* [ ] Work on pangenome genotyping 1U01HG013760
-* [+] Moni builds 1U01HG013760
# Tasks
@@ -51,11 +66,11 @@ Now (X=done +=WIP _=kickoff ?=?)
* [+] Build leadership team
* [+] gBAM
* [ ] p-value global search
-* [+] Xapian search add tags, notmuch style (with @zachs)
+* [+] Xapian search add tags, notmuch style (with @bonfacem and @zachs)
=> ../issues/systems/octopus
-* [ ] Add R/qtl2 and multi-parent support with Karl (DO and Magic populations)
+* [+] Add R/qtl2 and multi-parent support with Karl (DO and Magic populations)
* [+] Fix slow search on Mariadb? Moving to xapian
* [.] GeneNetwork paper
* + [ ] add FAIR statement
@@ -86,11 +101,7 @@ Later
### Set up stable server instance with new hardware
* [ ] ssh-shell access for git markdown
-* [ ] R/qtl2 with Karl and Alex
-* [+] Set up opensmtpd as a service
- + [ ] Add package dependency
- + [X] Test on open port 25
- + [ ] Add public-inbox (Arun)
+* [+] R/qtl2 with Karl and Alex, see [alex.gmi]
=> ./machine-room.gmi machine room
@@ -118,3 +129,12 @@ Later
* [X] Fix mariadb index search - need to upgrade mariadb to convert final utf8mb4, see
=> ../issues/slow-sql-query-for-xapian-indexing.gmi
* [X] Debian/free software issues incl. vcflib work in Zig and release
+* [X] Set up opensmtpd as a service
+
+# Notes
+
+The tasks here should probably be broken out into appropriately tagged issues, where they have not - they can be found and filtered out with tissue (formerly gnbug).
+
+=> https://issues.genenetwork.org
+
+Generally work applies to NIH/R073237482 and other grants.
diff --git a/tasks/programmer-team/meetings.gmi b/tasks/programmer-team/meetings.gmi
new file mode 100644
index 0000000..d972b3b
--- /dev/null
+++ b/tasks/programmer-team/meetings.gmi
@@ -0,0 +1,82 @@
+# Weekly meetings
+
+In this document we will track tasks based of our weekly meetings. This list sets the agenda
+on progress for the next week's meeting.
+
+## 02-10-2024
+## @felixm
+* [ ] Use Aider to contribute and cover to Fred's coding. Share useful prompts.
+* [ ] Feed relevant papers to GPT and find similar summary for other datasets. Start with C-Elegans.
+
+
+## @bonfacem
+* [ ] Share values with PJ.
+* [ ] Assume LMDB files are transient. When hash doesn't exist, generate the hash for that dataset. Use LMDB to store key value pairs of hashes.
+* [ ] Add dump script to gn-guile.
+* [ ] Add Case Attributes in Virtuoso.
+
+## @alex
+* [ ] Push R/QTL2 to production
+* [ ] Have R/QTL2 work for ITP
+
+Nice to have:
+* Think about editing publish data and consequent updates to LMDB.
+
+## @pjotr
+* Kickstart UTHSC VPN access for Felix and Alex.
+
+## 01-20-2024
+### @bonfacem
+
+* [ ] Report: OpenAI on Aider - use AI for programming - discuss with @alexm
+
+=> https://issues.genenetwork.org/topics/ai/aider
+
+* [-] Metadata: Provide list of case attributes for BXD to @flisso
+* [-] Code UI: GeneRIF and GenWiki should work from the mapping page - encourage people to use
+ - anyone logged in can edit
+ - If RIF does not exist point to GeneWiki
+ - If GeneWiki does not exist provide edit page
+* [ ] Code export: Exporting traits to lmdb PublishData - @alexm helps with SQL
+ - missing data should not be an X
+ - run lmdb design (first code) by @pjotrp
+ - start exporting traits for Johannes (he will need to write a python reader)
+* Later: Improve the work/dev container for @alexm
+
+### @flisso
+
+* [ ] Write: Uploader protocol. NOTES: Finished with C-elegans. Yet to test with other datasets.
+* [ ] Script: Run Reaper
+* [ ] Data: Case attributes - with @bonfacem
+* [ ] Write: Create protocol to upload case attributes
+
+### @alexm
+
+* [ ] Code: Rqtl2 match Rqtl1: match scan changes. Notes: PR out and added tests.
+* [ ] Bug: Fix pair scan. NOTES: Fixed it. But can't test it now since CD is down.
+* Later: AI changes
+
+### @Pjotr
+
+* [ ] Code: Work on precompute with GEMMA (w. Jameson)
+* [ ] Code: Take Bonface's trait files when they become available
+
+
+## 01-27-2024
+
+Last week's error with CD and production downtime:
+* [ level 1] Container: Error messages when data not loaded in Virtuoso, Indexing.
+* [ level 2] Sheepdog: Check services --- sheepdog. Health checkpoints.
+* [ level 3] User feedback. Escalate errors correctly to the users, so they can report to coders
+
+### @bonfacem
+* [ ] Troubleshoot CD.
+* [ ] Export files in lmdb. Yohannes read file in Python example
+* [ ] Metadata: Provide list of case attributes for BXD to @flisso
+* [ ] Aider: See if it can generate some guile and python. Give an example.
+
+### @alexm
+* [ ] UI for R/Qtl2.
+
+### @flisso
+* [ ] Look at Fred Python code for the uploader and report on this.
diff --git a/tasks/zachs.gmi b/tasks/zachs.gmi
new file mode 100644
index 0000000..6ae3df1
--- /dev/null
+++ b/tasks/zachs.gmi
@@ -0,0 +1,7 @@
+# Tasks for Zach
+
+# Tasks
+
+* [ ] Move non-ephemeral data out of redis into sqlite DB - see JSON dump
+* - [ ] Collections
+* - [ ] permanent URIs(?)
diff --git a/topics/ai/aider.gmi b/topics/ai/aider.gmi
index 71dfa9e..aa88e71 100644
--- a/topics/ai/aider.gmi
+++ b/topics/ai/aider.gmi
@@ -1,12 +1,16 @@
# Aider
-https://aider.chat/
+=> https://aider.chat/
+```
python3 -m venv ~/opt/python-aider
~/opt/python-aider/bin/python3 -m pip install aider-install
~/opt/python-aider/bin/aider-install
+```
Installed 1 executable: aider
Executable directory /home/wrk/.local/bin is already in PATH
+```
aider --model gpt-4o --openai-api-key aa...
+```
diff --git a/topics/ai/ontogpt.gmi b/topics/ai/ontogpt.gmi
new file mode 100644
index 0000000..94bd165
--- /dev/null
+++ b/topics/ai/ontogpt.gmi
@@ -0,0 +1,7 @@
+# OntoGPT
+
+python3 -m venv ~/opt/ontogpt
+~/opt/ontogpt/bin/python3 -m pip install ontogpt
+
+
+runoak set-apikey -e openai
diff --git a/topics/database/mariadb-database-architecture.gmi b/topics/database/mariadb-database-architecture.gmi
index 5c9b0c5..0454d71 100644
--- a/topics/database/mariadb-database-architecture.gmi
+++ b/topics/database/mariadb-database-architecture.gmi
@@ -28,6 +28,12 @@ Naming convention-wise there is a confusing use of id and data-id in particular.
The default install comes with a smaller database which includes a
number of the BXDs and the Human liver dataset (GSE9588).
+It can be downloaded from:
+
+=> https://files.genenetwork.org/database/
+
+Try the latest one first.
+
# GeneNetwork database
Estimated table sizes with metadata comment for the important tables
@@ -536,8 +542,8 @@ select * from ProbeSetSE limit 5;
For the other tables, you may check the GN2/doc/database.org document (the starting point for this document).
-# Contributions regarding data upload to the GeneNetwork webserver
-* Ideas shared by the GeneNetwork team to facilitate the process of uploading data to production
+# Contributions regarding data upload to the GeneNetwork webserver
+* Ideas shared by the GeneNetwork team to facilitate the process of uploading data to production
## Quality check and integrity of the data to be uploaded to gn2
@@ -556,7 +562,7 @@ For the other tables, you may check the GN2/doc/database.org document (the start
* Unique identifiers solve the hurdles that come with having duplicate genes. So, the QA tools in place should ensure the uploaded dataset adheres to the requirements mentioned
* However, newer RNA-seq data sets generated by sequencing do not usually have an official vendor identifier. The identifier is usually based on the NCBI mRNA model (NM_XXXXXX) that was used to evaluate an expression and on the sequence that is involved, usually the start and stop nucleotide positions based on a specific genome assembly or just a suffix to make sure it is unique. In this case, you are looking at mRNA assays for a single transcript, but different parts of the transcript that have different genome coordinates. We now typically use ENSEMBL identifiers.
* The mouse version of the sonic hedgehog gene as an example: `ENSMUST00000002708` or `ENSMUSG00000002633` sources should be fine. The important thing is to know the provenance of the ID—who is in charge of that ID type?
-* When a mRNA assay is super precise (one exon only or a part of the 5' UTR), then we should use exon identifiers from ENSEMBL probably.
+* When a mRNA assay is super precise (one exon only or a part of the 5' UTR), then we should use exon identifiers from ENSEMBL probably.
* Ideally, we should enter the sequence's first and last 100 nt in GeneNetwork for verification and alignment. We did this religiously for arrays, but have started to get lazy now. The sequence is the ultimate identifier
* For methylation arrays and CpG assays, we can use this format `cg14050475` as seen in MBD UTHSC Ben's data
* For metabolites like isoleucine—the ID we have been using is the mass-to-charge (MZ) ratio such as `130.0874220_MZ`
@@ -579,16 +585,16 @@ abcb10_q9ji39_t312
## BXD individuals
-* Basically groups (represented by the InbredSet tables) are primarily defined by their list of samples/strains (represented by the Strain tables). When we create a new group, it's because we have data with a distinct set of samples/strains from any existing groups.
-* So when we receive data for BXD individuals, as far as the database is concerned they are a completely separate group (since the list of samples is new/distinct from any other existing groups). We can choose to also enter it as part of the "generic" BXD group (by converting it to strain means/SEs using the strain of each individual, assuming it's provided like in the files Arthur was showing us).
+* Basically groups (represented by the InbredSet tables) are primarily defined by their list of samples/strains (represented by the Strain tables). When we create a new group, it's because we have data with a distinct set of samples/strains from any existing groups.
+* So when we receive data for BXD individuals, as far as the database is concerned they are a completely separate group (since the list of samples is new/distinct from any other existing groups). We can choose to also enter it as part of the "generic" BXD group (by converting it to strain means/SEs using the strain of each individual, assuming it's provided like in the files Arthur was showing us).
* This same logic could apply to other groups as well - we could choose to make one group the "strain mean" group for another set of groups that contain sample data for individuals. But the database doesn't reflect the relationship between these groups*
* As far as the database is concerned, there is no distinction between strain means and individual sample data - they're all rows in the ProbeSetData/PublishData tables. The only difference is that strain mean data will probably also have an SE value in the ProbeSetSE/PublishSE tables and/or an N (number of individuals per strain) value in the NStrain table
* As for what this means for the uploader - I think it depends on whether Rob/Arthur/etc wants to give users the ability to simultaneously upload both strain mean and individual data. For example, if someone uploads some BXD individuals' data, do we want the uploader to both create a new group for this (or add to an existing BXD individuals group) and calculate the strain means/SE and enter it into the "main" BXD group? My personal feeling is that it's probably best to postpone that for later and only upload the data with the specific set of samples indicated in the file since it would insert some extra complexity to the uploading process that could always be added later (since the user would need to select "the group the strains are from" as a separate option)
* The relationship is sorta captured in the CaseAttribute and CaseAttributeXRefNew tables (which contain sample metadata), but only in the form of the metadata that is sometimes displayed as extra columns in the trait page table - this data isn't used in any queries/analyses currently (outside of some JS filters run on the table itself) and isn't that important as part of the uploading process (or at least can be postponed)
-## Individual Datasets and Derivatives datasets in gn2
-* Individual dataset reflects the actual data provided or submitted by the investigator (user). Derivative datasets include the processed information from the individual dataset, as in the case of the average datasets.
-* An example of an individual dataset would look something like; (MBD dataset)
+## Individual Datasets and Derivatives datasets in gn2
+* Individual dataset reflects the actual data provided or submitted by the investigator (user). Derivative datasets include the processed information from the individual dataset, as in the case of the average datasets.
+* An example of an individual dataset would look something like; (MBD dataset)
```
#+begin_example
sample, strain, Sex, Age,…
@@ -600,13 +606,13 @@ FEB0005,BXD16,F,14,…
⋮
#+end_example
```
-* The strain column above has repetitive values. Each value has a one-to-many relationship with values on sample column. From this dataset, there can be several derivatives. For example;
-- Sex-based categories
-- Average data (3 sample values averaged to one strain value)
-- Standard error table computed for the averages
+* The strain column above has repetitive values. Each value has a one-to-many relationship with values on sample column. From this dataset, there can be several derivatives. For example;
+- Sex-based categories
+- Average data (3 sample values averaged to one strain value)
+- Standard error table computed for the averages
-## Saving data to database
-* Strain table schema
+## Saving data to database
+* Strain table schema
```
#+begin_src sql
MariaDB [db_webqtl]> DESC Strain;
@@ -639,21 +645,21 @@ FEB0005,BXD16,F,14,…
5 rows in set (0.00 sec)
#+end_src
```
-* Where the =InbredSetId= comes from the =InbredSet= table and the =StrainId= comes from the =Strain= table. The *individual data* would be linked to an inbredset group that is for individuals
+* Where the =InbredSetId= comes from the =InbredSet= table and the =StrainId= comes from the =Strain= table. The *individual data* would be linked to an inbredset group that is for individuals
* For the *average data*, the only value to save would be the =strain= field, which would be saved as =Name= in the =Strain= table and linked to an InbredSet group that is for averages
*Question 01*: How do we distinguish the inbredset groups?
*Answer*: The =Family= field is useful for this.
*Question 02*: If you have more derived "datasets", e.g. males-only, females-only, under-10-years, 10-to-25-years, etc. How would the =Strains= table handle all those differences?
-## Metadata
+## Metadata
* The data we looked at had =gene id= and =gene symbol= fields. These fields were used to fetch the *Ensembl ID* and *descriptions* from [[https://www.ncbi.nlm.nih.gov/][NCBI]] and the [[https://useast.ensembl.org/][Ensembl Genome Browser]]
-## Files for mapping
+## Files for mapping
* Files used for mapping need to be in =bimbam= or =.geno= formats. We would need to do conversions to at least one of these formats where necessary
-## Annotation files
-* Consider the following schema of DB tables
+## Annotation files
+* Consider the following schema of DB tables
#+begin_src sql
MariaDB [db_webqtl]> DESC InbredSet;
+-----------------+----------------------+------+-----+---------+----------------+
@@ -718,10 +724,10 @@ FEB0005,BXD16,F,14,…
- The =used_for_mapping= field should be set to ~Y~ unless otherwise informed
- The =PedigreeStatus= field is unknown to us for now: set to ~NULL~
-* Annotation file format
+* Annotation file format
The important fields are:
- =ChipId=: The platform that the data was collected from/with
-Consider the following table;
+Consider the following table;
#+begin_src sql
MariaDB [db_webqtl]> DESC GeneChip;
+---------------+----------------------+------+-----+---------+----------------+
@@ -744,7 +750,7 @@ Consider the following table;
- =Probe_set_Blat_Mb_start=/=Probe_set_Blat_Mb_end=: In Byron's and Beni's data, these correspond to the =geneStart= and =geneEnd= fields respectively. These are the positions, in megabasepairs, that the gene begins and ends at, respectively.
- =Mb=: This is the =geneStart=/=Probe_set_Blat_Mb_start= value divided by *1000000*. (*Note to self*: Maybe the Probe_set_Blat_Mb_* fields above might not be in megabase pairs — please confirm)
- =Strand_Probe= and =Strand_Gene=: These fields' values are simply ~+~ or ~-~. If these values are missing, you can [[https://ftp.ncbi.nih.gov/gene/README][retrieve them from NCBI]], specifically from the =orientation= field of seemingly any text file with the field
- - =Chr=: This is the chromosome on which the gene is found
+ - =Chr=: This is the chromosome on which the gene is found
* The final annotation file will have (at minimum) the following fields (or their
analogs):
@@ -765,8 +771,8 @@ analogs):
* =.geno= Files
- The =.geno= files have sample names, not the strain/symbol. The =Locus= field in the =.geno= file corresponds to the **marker**. =.geno= files are used with =QTLReaper=
- The sample names in the ~.geno~ files *MUST* be in the same order as the
-strains/symbols for that species. For example;
-Data format is as follows;
+strains/symbols for that species. For example;
+Data format is as follows;
```
#+begin_example
SampleName,Strain,…
@@ -779,7 +785,7 @@ BJCWI0005,BXD50,…
⋮
#+end_example
```
-and the order of strains is as follows;
+and the order of strains is as follows;
```
#+begin_example
…,BXD33,…,BXD40,…,BXD50,…
@@ -806,9 +812,9 @@ The order of samples that belong to the same strain is irrelevant - they share t
- Treatment
- Sex (Really? Isn't sex an expression of genes?)
- batch
- - Case ID, etc
+ - Case ID, etc
-* Summary steps to load data to the database
+* Summary steps to load data to the database
- [x] Create *InbredSet* group (think population)
- [x] Load the strains/samples data
- [x] Load the sample cross-reference data to link the samples to their
@@ -821,8 +827,4 @@ The order of samples that belong to the same strain is irrelevant - they share t
- [x] Load the *Log2* data (ProbeSetData and ProbeSetXRef tables)
- [x] Compute means (an SQL query was used — this could be pre-computed in code
and entered along with the data)
-- [x] Run QTLReaper
-
-
-
-
+- [x] Run QTLReaper
diff --git a/topics/deploy/installation.gmi b/topics/deploy/installation.gmi
index 757d848..d6baa79 100644
--- a/topics/deploy/installation.gmi
+++ b/topics/deploy/installation.gmi
@@ -319,7 +319,7 @@ Currently we have two databases for deployment,
from BXD mice and 'db_webqtl_plant' which contains all plant related
material.
-Download one database from
+Download a recent database from
=> https://files.genenetwork.org/database/
diff --git a/topics/genenetwork-releases.gmi b/topics/genenetwork-releases.gmi
new file mode 100644
index 0000000..e179629
--- /dev/null
+++ b/topics/genenetwork-releases.gmi
@@ -0,0 +1,77 @@
+# GeneNetwork Releases
+
+## Tags
+
+* status: open
+* priority:
+* assigned:
+* type: documentation
+* keywords: documentation, docs, release, releases, genenetwork
+
+## Introduction
+
+The sections that follow will be note down the commits used for various stable (and stable-ish) releases of genenetwork.
+
+The tagging of the commits will need to distinguish repository-specific tags from overall system tags.
+
+In this document, we only concern ourselves with the overall system tags, that shall have the template:
+
+```
+genenetwork-system-v<major>.<minor>.<patch>[-<commit>]
+```
+
+the portions in angle brackets will be replaced with the actual version numbers.
+
+## genenetwork-system-v1.0.0
+
+This is the first, guix-system-container-based, stable release of the entire genenetwork system.
+The commits involved are:
+
+=> https://github.com/genenetwork/genenetwork2/commit/314c6d597a96ac903071fcb6e50df3d9e88935e9 GN2: 314c6d5
+=> https://github.com/genenetwork/genenetwork3/commit/0d902ec267d96b87648669a7a43b699c8a22a3de GN3: 0d902ec
+=> https://git.genenetwork.org/gn-auth/commit/?id=8e64f7f8a392b8743a4f36c497cd2ec339fcfebc: gn-auth: 8e64f7f
+=> https://git.genenetwork.org/gn-libs/commit/?id=72a95f8ffa5401649f70978e863dd3f21900a611: gn-libs: 72a95f8
+
+The guix channels used for deployment of the system above are as follows:
+
+```
+(list (channel
+ (name 'guix-bioinformatics)
+ (url "https://git.genenetwork.org/guix-bioinformatics/")
+ (branch "master")
+ (commit
+ "039a3dd72c32d26b9c5d2cc99986fd7c968a90a5"))
+ (channel
+ (name 'guix-forge)
+ (url "https://git.systemreboot.net/guix-forge/")
+ (branch "main")
+ (commit
+ "bcb3e2353b9f6b5ac7bc89d639e630c12049fc42")
+ (introduction
+ (make-channel-introduction
+ "0432e37b20dd678a02efee21adf0b9525a670310"
+ (openpgp-fingerprint
+ "7F73 0343 F2F0 9F3C 77BF 79D3 2E25 EE8B 6180 2BB3"))))
+ (channel
+ (name 'guix-past)
+ (url "https://gitlab.inria.fr/guix-hpc/guix-past")
+ (branch "master")
+ (commit
+ "5fb77cce01f21a03b8f5a9c873067691cf09d057")
+ (introduction
+ (make-channel-introduction
+ "0c119db2ea86a389769f4d2b9c6f5c41c027e336"
+ (openpgp-fingerprint
+ "3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5"))))
+ (channel
+ (name 'guix)
+ (url "https://git.savannah.gnu.org/git/guix.git")
+ (branch "master")
+ (commit
+ "2394a7f5fbf60dd6adc0a870366adb57166b6d8b")
+ (introduction
+ (make-channel-introduction
+ "9edb3f66fd807b096b48283debdcddccfea34bad"
+ (openpgp-fingerprint
+ "BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA")))))
+```
diff --git a/topics/systems/backup-drops.gmi b/topics/systems/backup-drops.gmi
index 191b185..a4677f7 100644
--- a/topics/systems/backup-drops.gmi
+++ b/topics/systems/backup-drops.gmi
@@ -4,6 +4,10 @@ To make backups we use a combination of sheepdog, borg, sshfs, rsync. sheepdog i
This system proves pretty resilient over time. Only on the synology server I can't get it to work because of some CRON permission issue.
+For doing the actual backups see
+
+=> ./backups-with-borg.gmi
+
# Tags
* assigned: pjotrp
@@ -13,7 +17,7 @@ This system proves pretty resilient over time. Only on the synology server I can
## Borg backups
-It is advised to use a backup password and not store that on the remote.
+Despite our precautions it is advised to use a backup password and *not* store that on the remote.
## Running sheepdog on rabbit
@@ -59,14 +63,14 @@ where remote can be an IP address.
Warning: if you introduce this `AllowUsers` command all users should be listed or people may get locked out of the machine.
-Next create a special key on the backup machine's ibackup user (just hit enter):
+Next create a special password-less key on the backup machine's ibackup user (just hit enter):
```
su ibackup
ssh-keygen -t ecdsa -f $HOME/.ssh/id_ecdsa_backup
```
-and copy the public key into the remote /home/bacchus/.ssh/authorized_keys
+and copy the public key into the remote /home/bacchus/.ssh/authorized_keys.
Now test it from the backup server with
@@ -82,13 +86,20 @@ On the drop server you can track messages by
tail -40 /var/log/auth.log
```
+or on recent linux with systemd
+
+```
+journalctl -r
+```
+
Next
```
ssh -v -i ~/.ssh/id_ecdsa_backup bacchus@dropserver
```
-should give a Broken pipe(!). In auth.log you may see something like
+should give a Broken pipe(!) or it says `This service allows sftp connections only`.
+When running sshd with a verbose switch you may see something like
fatal: bad ownership or modes for chroot directory component "/export/backup/"
@@ -171,3 +182,5 @@ sshfs -o reconnect,ServerAliveInterval=15,ServerAliveCountMax=3,IdentityFile=~/.
The recent scripts can be found at
=> https://github.com/genenetwork/gn-deploy-servers/blob/master/scripts/tux01/backup_drop.sh
+
+# borg-borg
diff --git a/topics/systems/backups-with-borg.gmi b/topics/systems/backups-with-borg.gmi
new file mode 100644
index 0000000..5cdb2a3
--- /dev/null
+++ b/topics/systems/backups-with-borg.gmi
@@ -0,0 +1,202 @@
+# Borg backups
+
+We use borg for backups. Borg is an amazing tool and after 25+ years of making backups it just feels right.
+With the new tux04 production install we need to organize backups off-site. The first step is to create a
+borg runner using sheepdog -- sheepdog we use for monitoring success/failure.
+Sheepdog essentially wraps a Unix command and sends a report to a local or remote redis instance.
+Sheepdog also includes a web server for output:
+
+=> http://sheepdog.genenetwork.org/sheepdog/status.html
+
+# Tags
+
+* assigned: pjotrp
+* keywords: systems, backup, sheepdog, database
+
+# Install borg
+
+Usually I use a version of borg from guix. This should really be done as the borg user (ibackup).
+
+```
+mkdir ~/opt
+guix package -i borg ~/opt/borg
+tux04:~$ ~/opt/borg/bin/borg --version
+ 1.2.2
+```
+
+# Create a new backup dir and user
+
+The backup should live on a different disk from the things we backup, so when that disk fails we have another.
+
+The SQL database lives on /export and the containers live on /export2. /export3 is a largish slow drive, so perfect.
+
+By convention I point /export/backup to the real backup dir on /export3/backup/borg/ Another convention is that we use an ibackup user which has the backup passphrase in ~/.borg-pass. As root:
+
+```
+mkdir /export/backup/borg
+chown ibackup:ibackup /export/backup/borg
+chown ibackup:ibackup /home/ibackup/.borg-pass
+su ibackup
+```
+
+Now you should be able to load the passphrase and create the backup dir
+
+```
+id
+ uid=1003(ibackup)
+. ~/.borg-pass
+cd /export/backup/borg
+~/opt/borg/bin/borg init --encryption=repokey-blake2 genenetwork
+```
+
+Now we can run our first backup. Note that ibackup should be a member of the mysql and gn groups
+
+```
+mysql:x:116:ibackup
+```
+
+# First backup
+
+Run the backup the first time:
+
+```
+id
+ uid=1003(ibackup) groups=1003(ibackup),116(mysql)
+~/opt/borg/bin/borg create --progress --stats genenetwork::first-backup /export/mysql/database/*
+```
+
+You may first need to update permissions to give group access
+
+```
+chmod g+rx -R /var/lib/mysql/*
+```
+
+When that works borg reports:
+
+```
+Archive name: first-backup
+Archive fingerprint: 376d32fda9738daa97078fe4ca6d084c3fa9be8013dc4d359f951f594f24184d
+Time (start): Sat, 2025-02-08 04:46:48
+Time (end): Sat, 2025-02-08 05:30:01
+Duration: 43 minutes 12.87 seconds
+Number of files: 799
+Utilization of max. archive size: 0%
+------------------------------------------------------------------------------
+ Original size Compressed size Deduplicated size
+This archive: 534.24 GB 238.43 GB 237.85 GB
+All archives: 534.24 GB 238.43 GB 238.38 GB
+ Unique chunks Total chunks
+Chunk index: 200049 227228
+------------------------------------------------------------------------------
+```
+
+50% compression is not bad. borg is incremental so it will only backup differences next round.
+
+Once borg works we could run a CRON job. But we should use the sheepdog monitor to make sure backups keep going without failure going unnoticed.
+
+# Using the sheepdog
+
+=> https://github.com/pjotrp/deploy sheepdog code
+
+## Clone sheepdog
+
+=> https://github.com/pjotrp/deploy#install sheepdog install
+
+Essentially clone the repo so it shows up in ~/deploy
+
+```
+cd /home/ibackup
+git clone https://github.com/pjotrp/deploy.git
+/export/backup/scripts/tux04/backup-tux04.sh
+```
+
+## Setup redis
+
+All sheepdog messages get pushed to redis. You can run it locally or remotely.
+
+By default we use redis, but syslog and others may also be used. The advantage of redis is that it is not bound to the same host, can cross firewalls using an ssh reverse tunnel, and is easy to query.
+
+=> https://github.com/pjotrp/deploy#install sheepdog install
+
+In our case we use redis on a remote host and the results get displayed by a webserver. Also some people get E-mail updates on failure. The configuration is in
+
+```
+/home/ibackup# cat .config/sheepdog/sheepdog.conf .
+{
+ "redis": {
+ "host" : "remote-host",
+ "password": "something"
+ }
+}
+```
+
+If you see localhost with port 6377 it is probably a reverse tunnel setup:
+
+=> https://github.com/pjotrp/deploy#redis-reverse-tunnel
+
+Update the fields according to what we use. Main thing is that is the definition of the sheepdog->redis connector. If you also use sheepdog as another user you'll need to add a config.
+
+Sheepdog should show a warning when you configure redis and it is not connecting.
+
+## Scripts
+
+Typically I run the cron job from root CRON so people can find it. Still it is probably a better idea to use an ibackup CRON. In my version a script is run that also captures output:
+
+```cron root
+0 6 * * * /bin/su ibackup -c /export/backup/scripts/tux04/backup-tux04.sh >> ~/cron.log 2>&1
+```
+
+The script contains something like
+
+```bash
+#! /bin/bash
+if [ "$EUID" -eq 0 ]
+ then echo "Please do not run as root. Run as: su ibackup -c $0"
+ exit
+fi
+rundir=$(dirname "$0")
+# ---- for sheepdog
+source $rundir/sheepdog_env.sh
+cd $rundir
+sheepdog_borg.rb -t borg-tux04-sql --group ibackup -v -b /export/backup/borg/genenetwork /export/mysql/database/*
+```
+
+and the accompanying sheepdov_env.sh
+
+```
+export GEM_PATH=/home/ibackup/opt/deploy/lib/ruby/vendor_ruby
+export PATH=/home/ibackup/opt/deploy/deploy/bin:/home/wrk/opt/deploy/bin:$PATH
+```
+
+If it reports
+
+```
+/export/backup/scripts/tux04/backup-tux04.sh: line 11: /export/backup/scripts/tux04/sheepdog_env.sh: No such file or directory
+```
+
+you need to install sheepdog first.
+
+If all shows green (and takes some time) we made a backup. Check the backup with
+
+```
+ibackup@tux04:/export/backup/borg$ borg list genenetwork/
+first-backup Sat, 2025-02-08 04:39:50 [58715b883c080996ab86630b3ae3db9bedb65e6dd2e83977b72c8a9eaa257cdf]
+borg-tux04-sql-20250209-01:43-Sun Sun, 2025-02-09 01:43:23 [5e9698a032143bd6c625cdfa12ec4462f67218aa3cedc4233c176e8ffb92e16a]
+```
+and you should see the latest. The contents with all files should be visible with
+
+```
+borg list genenetwork::borg-tux04-sql-20250209-01:43-Sun
+```
+
+Make sure you not only see just a symlink.
+
+# More backups
+
+Our production server runs databases and file stores that need to be backed up too.
+
+# Drop backups
+
+Once backups work it is useful to copy them to a remote server, so when the machine stops functioning we have another chance at recovery. See
+
+=> ./backup-drops.gmi
diff --git a/topics/systems/ci-cd.gmi b/topics/systems/ci-cd.gmi
index 6aa17f2..a1ff2e3 100644
--- a/topics/systems/ci-cd.gmi
+++ b/topics/systems/ci-cd.gmi
@@ -31,7 +31,7 @@ Arun has figured out the CI part. It runs a suitably configured laminar CI servi
CD hasn't been figured out. Normally, Guix VMs and containers created by `guix system` can only access the store read-only. Since containers don't have write access to the store, you cannot `guix build' from within a container or deploy new containers from within a container. This is a problem for CD. How do you make Guix containers have write access to the store?
-Another alternative for CI/ CID were to have the quick running tests, e.g unit tests, run on each commit to branch "main". Once those are successful, the CI/CD system we choose should automatically pick the latest commit that passed the quick running tests for for further testing and deployment, maybe once an hour or so. Once the next battery of tests is passed, the CI/CD system will create a build/artifact to be deployed to staging and have the next battery of tests runs against it. If that passes, then that artifact could be deployed to production, and details on the commit and
+Another alternative for CI/ CD were to have the quick running tests, e.g unit tests, run on each commit to branch "main". Once those are successful, the CI/CD system we choose should automatically pick the latest commit that passed the quick running tests for for further testing and deployment, maybe once an hour or so. Once the next battery of tests is passed, the CI/CD system will create a build/artifact to be deployed to staging and have the next battery of tests runs against it. If that passes, then that artifact could be deployed to production, and details on the commit and
#### Possible Steps
@@ -90,3 +90,49 @@ This contains a check-list of things that need to be done:
=> /topics/systems/orchestration Orchestration
=> /issues/broken-cd Broken-cd (Resolved)
+
+## Adding a web-hook
+
+### Github hooks
+
+IIRC actions run artifacts inside github's infrastracture. We use webhooks: e.g.
+
+Update the hook at
+
+=> https://github.com/genenetwork/genenetwork3/settings/hooks
+
+=> ./screenshot-github-webhook.png
+
+To trigger CI manually, run this with the project name:
+
+```
+curl https://ci.genenetwork.org/hooks/example-gn3
+```
+
+For gemtext we have a github hook that adds a forge-project and looks like
+
+```lisp
+(define gn-gemtext-threads-project
+ (forge-project
+ (name "gn-gemtext-threads")
+ (repository "https://github.com/genenetwork/gn-gemtext-threads/")
+ (ci-jobs (list (forge-laminar-job
+ (name "gn-gemtext-threads")
+ (run (with-packages (list nss-certs openssl)
+ (with-imported-modules '((guix build utils))
+ #~(begin
+ (use-modules (guix build utils))
+
+ (setenv "LC_ALL" "en_US.UTF-8")
+ (invoke #$(file-append tissue "/bin/tissue")
+ "pull" "issues.genenetwork.org"))))))))
+ (ci-jobs-trigger 'webhook)))
+```
+
+Guix forge can be found at
+
+=> https://git.systemreboot.net/guix-forge/
+
+### git.genenetwork.org hooks
+
+TBD
diff --git a/topics/systems/screenshot-github-webhook.png b/topics/systems/screenshot-github-webhook.png
new file mode 100644
index 0000000..08feed3
--- /dev/null
+++ b/topics/systems/screenshot-github-webhook.png
Binary files differ
generated by cgit v1.2.3 (git 2.47.1) at 2025-04-13 08:04:03 +0000