Jump to content

Sn3akyP3t3

Members
  • Content Count

    52
  • Joined

  • Last visited

Community Reputation

1 Neutral

About Sn3akyP3t3

  • Rank
    Advanced Member

Converted

  • Gender
    Undisclosed
  • Location
    Earth
  • Personal Text
    Intentionally left blank

Recent Profile Visitors

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

  1. I worked on the server this weekend and got a reverse proxy setup following this tutorial. I tried to turn around and apply the letsencrypt generated key pair to the mosquitto mqtt container through the /config directory and modified the mosquitto.conf file to make use of the keys, but the service isn't able to launch as there is something not agreeable with the key pair. I commented out the config lines referencing the key and found the files are accessible from within the container. The logs don't say a lot about what the problem could be so I'm wondering if there is a way to enable debug logging for the eclipse-mosquitto, but that may take a little experimentation to build that container with logging enabled. Is there a technique to apply keys created by the letsencrypt container into other containers? The eclipse-mosquitto container expects the keys to be with the application on startup using these lines to enable: listener 8883 protocol mqtt certfile /config/ssh/cert.pem cafile /config/ssh/chain.pem keyfile /config/ssh/privkey.pem
  2. Huh.. looks like these are symbolic links. lrwxrwxrwx 1 root root 19 Jul 7 00:31 EVP_get_digestbynid.3.gz -> EVP_DigestInit.3.gz lrwxrwxrwx 1 root root 19 Jul 7 00:31 EVP_get_digestbyobj.3.gz -> EVP_DigestInit.3.gz lrwxrwxrwx 1 root root 17 Jul 7 00:31 EVP_idea_cfb.3.gz -> EVP_idea_cbc.3.gz lrwxrwxrwx 1 root root 17 Jul 7 00:31 EVP_idea_cfb64.3.gz -> EVP_idea_cbc.3.gz lrwxrwxrwx 1 root root 17 Jul 7 00:31 EVP_idea_ecb.3.gz -> EVP_idea_cbc.3.gz lrwxrwxrwx 1 root root 17 Jul 7 00:31 EVP_idea_ofb.3.gz -> EVP_idea_cbc.3.gz lrwxrwxrwx 1 root root 12 Jul 7 00:31 EVP_md5_sha1.3.gz -> EVP_md5.3.gz
  3. I don't often terminal into the UnRaid server unless I'm changing something or troubleshooting. I stumbled upon this and was immediately curious. Running the below command on the root directory reveals there are 3380 gun zip archive files stored right at the root directory level which is highly unusual for any Linux machine I've ever managed. Is this something I should clean up or is it a bug? I don't work with .gz files for anything I script so this wasn't caused by me directly. I'll crack open a handful of the files to see if there's anything fishy going on. Meanwhile I'm posting this to see if there is anything known about this. root@TrumpIsNotSmart:/# ls -1q *.gz | wc -l 3380 This is one of many pages captured to reveal the file names found in this pile of .gz stuffs ACCESS_DESCRIPTION_free.3.gz@ OpenSSL_add_ssl_algorithms.3.gz@ ACCESS_DESCRIPTION_new.3.gz@ OpenSSL_version.3.gz@ ADMISSIONS_free.3.gz@ OpenSSL_version_num.3.gz@ ADMISSIONS_get0_admissionAuthority.3.gz@ PBE2PARAM_free.3.gz@ ADMISSIONS_get0_namingAuthority.3.gz@ PBE2PARAM_new.3.gz@ ADMISSIONS_get0_professionInfos.3.gz@ PBEPARAM_free.3.gz@ ADMISSIONS_new.3.gz@ PBEPARAM_new.3.gz@ ADMISSIONS_set0_admissionAuthority.3.gz@ PBKDF2PARAM_free.3.gz@ ADMISSIONS_set0_namingAuthority.3.gz@ PBKDF2PARAM_new.3.gz@ ADMISSIONS_set0_professionInfos.3.gz@ PEM_FLAG_EAY_COMPATIBLE.3.gz@ ADMISSION_SYNTAX.3.gz@ PEM_FLAG_ONLY_B64.3.gz@ ADMISSION_SYNTAX_free.3.gz@ PEM_FLAG_SECURE.3.gz@ ADMISSION_SYNTAX_get0_admissionAuthority.3.gz@ PEM_bytes_read_bio_secmem.3.gz@ ADMISSION_SYNTAX_get0_contentsOfAdmissions.3.gz@ PEM_do_header.3.gz@ ADMISSION_SYNTAX_new.3.gz@ PEM_get_EVP_CIPHER_INFO.3.gz@ ADMISSION_SYNTAX_set0_admissionAuthority.3.gz@ PEM_read_DHparams.3.gz@ ADMISSION_SYNTAX_set0_contentsOfAdmissions.3.gz@ PEM_read_DSAPrivateKey.3.gz@ ASIdOrRange_free.3.gz@ PEM_read_DSA_PUBKEY.3.gz@ ASIdOrRange_new.3.gz@ PEM_read_DSAparams.3.gz@ ASIdentifierChoice_free.3.gz@ PEM_read_ECPKParameters.3.gz@ ASIdentifierChoice_new.3.gz@ PEM_read_ECPrivateKey.3.gz@ ASIdentifiers_free.3.gz@ PEM_read_EC_PUBKEY.3.gz@ ASIdentifiers_new.3.gz@ PEM_read_NETSCAPE_CERT_SEQUENCE.3.gz@ ASN1_ENUMERATED_get.3.gz@ PEM_read_PKCS7.3.gz@ ASN1_ENUMERATED_get_int64.3.gz@ PEM_read_PKCS8.3.gz@ ASN1_ENUMERATED_set.3.gz@ PEM_read_PKCS8_PRIV_KEY_INFO.3.gz@ ASN1_ENUMERATED_set_int64.3.gz@ PEM_read_PUBKEY.3.gz@ ASN1_ENUMERATED_to_BN.3.gz@ PEM_read_PrivateKey.3.gz@ ASN1_GENERALIZEDTIME_adj.3.gz@ PEM_read_RSAPrivateKey.3.gz@ ASN1_GENERALIZEDTIME_check.3.gz@ PEM_read_RSAPublicKey.3.gz@ ASN1_GENERALIZEDTIME_print.3.gz@ PEM_read_RSA_PUBKEY.3.gz@ ASN1_GENERALIZEDTIME_set.3.gz@ PEM_read_SSL_SESSION.3.gz@ ASN1_GENERALIZEDTIME_set_string.3.gz@ PEM_read_X509.3.gz@ ASN1_INTEGER_get.3.gz@ PEM_read_X509_AUX.3.gz@ ASN1_INTEGER_get_uint64.3.gz@ PEM_read_X509_CRL.3.gz@ ASN1_INTEGER_set.3.gz@ PEM_read_X509_REQ.3.gz@ ASN1_INTEGER_set_int64.3.gz@ PEM_read_bio.3.gz@ ASN1_INTEGER_set_uint64.3.gz@ PEM_read_bio_CMS.3.gz@ ASN1_INTEGER_to_BN.3.gz@ PEM_read_bio_DHparams.3.gz@ ASN1_ITEM.3.gz@ PEM_read_bio_DSAPrivateKey.3.gz@ ASN1_ITEM_get.3.gz@ PEM_read_bio_DSA_PUBKEY.3.gz@ ASN1_OBJECT_free.3.gz@ PEM_read_bio_DSAparams.3.gz@ ASN1_STRING_TABLE.3.gz@ PEM_read_bio_ECPKParameters.3.gz@ ASN1_STRING_TABLE_cleanup.3.gz@ PEM_read_bio_EC_PUBKEY.3.gz@ ASN1_STRING_TABLE_get.3.gz@ PEM_read_bio_NETSCAPE_CERT_SEQUENCE.3.gz@ ASN1_STRING_cmp.3.gz@ PEM_read_bio_PKCS7.3.gz@ ASN1_STRING_data.3.gz@ PEM_read_bio_PKCS8.3.gz@ ASN1_STRING_dup.3.gz@ PEM_read_bio_PKCS8_PRIV_KEY_INFO.3.gz@ ASN1_STRING_free.3.gz@ PEM_read_bio_PUBKEY.3.gz@ ASN1_STRING_get0_data.3.gz@ PEM_read_bio_RSAPrivateKey.3.gz@ ASN1_STRING_print.3.gz@ PEM_read_bio_RSAPublicKey.3.gz@ ASN1_STRING_print_ex_fp.3.gz@ PEM_read_bio_RSA_PUBKEY.3.gz@ ASN1_STRING_set.3.gz@ PEM_read_bio_SSL_SESSION.3.gz@ ASN1_STRING_to_UTF8.3.gz@ PEM_read_bio_X509.3.gz@ ASN1_STRING_type.3.gz@ PEM_read_bio_X509_AUX.3.gz@ ASN1_STRING_type_new.3.gz@ PEM_read_bio_X509_CRL.3.gz@ ASN1_TIME_adj.3.gz@ PEM_read_bio_X509_REQ.3.gz@ ASN1_TIME_check.3.gz@ PEM_write.3.gz@ ASN1_TIME_cmp_time_t.3.gz@ PEM_write_CMS.3.gz@ ASN1_TIME_compare.3.gz@ PEM_write_DHparams.3.gz@ ASN1_TIME_diff.3.gz@ PEM_write_DHxparams.3.gz@ ASN1_TIME_normalize.3.gz@ PEM_write_DSAPrivateKey.3.gz@
  4. @pappaq are you by chance using DDR4-2666 SODIMM for RAM and using 16 GB? The specs on the ASRock J4105 say one thing, but users say capacity is actually 16 GB RAM and Crucial.com says that its ok with DDR4-2666 SODIMM. So weird!
  5. Probably won't matter to many people, but if you do cross-platform Python scripting on UnRaid and the script inspects what environment it is running from you may be in need to fix your script. The recent version of UnRaid 6.7 has changed the case for good reasons I'm sure Here's the change: >>> print(platform.release()) 4.19.41-Unraid It used to be this case "unRAID". The solution is to make it case insensitive like so: if "unraid" in platform.release().lower() meh... details! Anyway, hope this helps someone out there.
  6. Excellent! That's exactly the news I wanted to hear! I'm not looking for anything with large power draws. I ended up getting a ASRock J3455-ITX which is easy to miss the omitted "B" in the model. This unit features 4x SATA instead of 2x, but with a loss of 0.2 GHz which doesn't bother me.
  7. Ah, x86, I was trying to stay away from the somewhat costly Udoo x68 units due to cost. I'll take a look at the ASRock boards like the J3455B-ITX and check for compatibility. That should be power effective enough.
  8. I used to have a backup solution with Crash Plan. I haven't restored my remote backup setup since they gave up on regular people and went with the business folk only. I've been shopping around for some years, but the cost per month for my needs are a bit too high. (Amazon banning rsync didn't help...) I'm looking now to host my own remote backup solution, but I don't want my remote host to incur extreme maintenance costs in power. I've been looking around for a SATA compatible extreme low cost board and found the Helios4 which is about the same cost to purchase as what I would pay per year to store the data. Sadly, I can't find any information if the Helios4 board is compatible with UnRAID or if anyone has experience with this. I figure the best option for backing up UnRAID is to have another UnRAID to store a subset of data. I'm pretty sure I would have encryption enabled for security. I would likely run a small number of features on this server, but not too much as to avoid exceeding the small amount of RAM available. I plan to give 50% of the storage space available to the host for kindly allowing me remote backup so they can stop using flash drives to backup their photos which is a bad option. I may in turn also setup remote backup for this person at my location so they also have a proper backup solution in place. Ideas or alternatives to the Helios4 option? Remember, I'm looking for an extreme low power option with little to no noise. If it can be passive cooling that would be a plus, but not essential.
  9. I love that UnRaid 6.7 just rolled out with Telegram. I think the number of agents will increase over time. Currently I count 8 different agents available. Many of us use more than one agent outside of UnRaid for various reasons. Some agents are more flexible than others and get used with enhanced tools such as Tasker or home automation. This allows tight notification elevation control which may interrupt a movie to alert of a problem for example or break the "do not disturb" setting for an important announcement. Also, some agents have limits such as Pushbullet which can be easily exceeded in a short time with lots of chatter. I propose that UnRaid support an additional mechanism to control which agent is subscribed to whichever topic the user selects. The provided annotated screenshots should explain this well.
  10. Whalla! UnRaid 6.7 is released and this feature is now available!
  11. @BRiT I'm interested in native Telegram notification agent support vice an SMTP workaround. There is only one given SMTP setting for email in UnRaid and its already involved in a notification workflow and I'd rather not disturb that for the sake of enabling another agent that is already potentially inbound for support within UnRaid if what was said above is true by @Kewjoe.
  12. Additionally, if you are using Two Factor Authentication you will need to create an app password and use that vice your Google Account credentials.
  13. I must have captured a version of GitLab that had this short-lived defect. An update to the image corrected this behavior... yuck!
  14. Does anyone have a long-term solution to this problem where the container refuses to stay running? I've found a temporary solution, but an update wipes this out, https://oplatform.club/t/topic/50 Image attached shows logging details of the failure to startup.
  15. All I know is that in this case, the scripts failed to run after the update to 6.4. I'm not keen on the underlying changes made and what impacts they may or may not have. Xvfb worked before, but not after. Docker permissions likely were the same as before, but because Xvfb suddenly failed I was forced to seek out an alternative which uncovered the permissions issue.