• 6 Posts
  • 79 Comments
Joined 3 years ago
cake
Cake day: June 28th, 2023

help-circle


  • brokenlcd@feddit.ittocats@lemmy.world•Helpful kitty
    link
    fedilink
    arrow-up
    13
    ·
    11 months ago

    I still remember when my cousin’s cat chewed through the pellet stove’s power cord… I don’t think I’ve ever heard a sound that so perfectly matched the expression “screams from hell”. Luckily the RCD tripped so the poor bastard survived. But he sure as hell isn’t touching wires again.


  • i’m not sure if it’s equivalent. but in the meantime i have cobbled up a series of commands from various forums to do the whole process, and i came up with the following openssl commands.

    openssl genrsa -out servorootCA.key 4096
    
    openssl req -x509 -new -nodes -key servorootCA.key -sha256 -days 3650 -out servorootCA.pem
    
    openssl genrsa -out star.servo.internal.key 4096
    
    openssl req -new -key star.servo.internal.key -out star.servo.internal.csr
    
    openssl x509 -req -in star.servo.internal.csr -CA servorootCA.pem -CAkey servorootCA.key -CAcreateserial -out star.servo.internal.crt -days 3650 -sha256 -extfile openssl.cnf -extensions v3_req
    

    with only the crt and key files on the server, while the rest is on a usb stick for keeping them out of the way.

    hopefully it’s the same. though i’ll still go through the book out of curiosity… and come to think of it. i do also need to setup calibre :-).

    thanks for everything. i’ll have to update the post with the full solution after i’m done, since it turned out to be a lot more messy than anticipated…


  • Don’t worry. Lemmy is asynchronous after all. Instant responses aren’t expected. Plus. I know life gets in the way :-).

    It was basically a misconception I had about how the homelab router would route the connection

    Basically with pihole set up. It routes servo.internal to 192.168.1.y, the IP of the homelab router. So when a machine from the inside of the homelab. On 10.0.0.*, connects to the server. It will refer to it via the 192.168.1.y IP of the router.

    The misconception was that I thought all the traffic was going to bounce between the homelab router and the home router. Going through the horrendously slow LAN cable that connects them and crippling the bandwidth between 10.0.0.* machines and the server.

    I wanted to setup another pihole server for inside of the homelab. So it would directly connect to the server on it’s 10.0.0.* address instead of the 192.168.1.y. And not go and bounce needlessly between the two routers.

    But apparently the homelab router realizes he’s speaking to itself. And routes the data directly to the server. Without passing though the home router and the slower Ethernet. So the issue is nonexistent, and I can use one pihole instance with 192.168.1.y for the server without issue. (Thanks to darkan15 for explaining that).

    While I do have my self-learned self-hosted knowledge, I’m not an IT guy, so I may be mistaken here and there.

    I think most of us are in a similar situation. Hell. I weld for a living atm :-P.

    However, I can give you a diagram on How it works on my setup right now and also gift you a nice ebook to help you setup your mini-CA for your lan :

    The diagram would be useful. Considering that rn I’m losing my mind between man pages.

    As for the book… I can’t accept. Just give me the name/ISBN and I’ll provide myself. Still. Thanks for the offer.


  • No, the request would stop on Router B, and maintain all traffic, on the 10.0.0.* network it would not change subnets, or anything

    OK perfect. That was my hiccup. I thought it was going to go the roundabout way and slow the traffic down. I was willing to Put in numbers (masking them with the landing page buttons) if it meant I wouldn’t have to go needlessly through the slower cable. If the router keeps everything inside of it’s own subnet if he realizes he’s talking to itself then it’s perfect.

    Thanks for the help


  • I think I didn’t explain myself the right way.

    Computers from inside of Router B will access the server via it’s IP. Nginx will only serve an HTML file with the links for them. Basically acting as a bookmark page for the IP:port combos. While anything from Router A will receive a landing page that has the subdomains, that will be resolved by pihole (exposed to the machines on Router A as an open port on router b) and will make them pass through the proxy.

    So basically the DNS will only be used on machines from Router A, and the rules on nginx are just to give links to the reverse proxy if the machine is from router A (I.e. the connection is coming from 10.0.0.1 from the server’s POV, or maybe the server name in the request. I’ll have to mess with nginx), or the page with the raw IP of the server+ port of the service if coming from Router B.

    router A is Unfortunately junk from my ISP, and it doesn’t allow me to change the DNS. So I’ll just add Router B ( and thus, the pihole instance that’s on the server) as a primary dns, and an external one as a secondary DNS as fallback.

    If you decide on doing the secondary local DNS on the server on Router B network, there is no need to loop back, as that DNS will maintain domain lookup and the requests on 10.0.0.x all internal to Router B network

    Wouldn’t this link to the 192.168.0.y address of router B pass through router A, and loop back to router B, routing through the slower cable? Or is the router smart enough to realize he’s just talking to itself and just cut out `router A from the traffic?


  • I think I’ll do this with one modification. I’ll make nginx serve the landing page with the subdomains when computers from router A try to access. ( by telling nginx to serve the page with the subdomains when contacted by 10.0.0.1) while I’ll serve another landing page that bypasses the proxy, by giving the direct 10.0.0.* IP of the server with the port, for computers inside router B .

    Mostly since the Ethernet between router a and b is old. And limits transfers to 10Mbps. So I’d be handicapping computers inside router B by looping back. Especially since everything inside router B is supposed to be safe. And they’ll be the ones transferring most of the data to it.

    Thanks for the breakdown. It genuinely helped in understanding the Daedalus-worthy path the connections need to take. I’ll update the post with my final solution and config once I make it work.


  • I think that pihole would be the best option. But coming to think of it… I think that to make it work I’d need two instances of pihole. Since the server is basically straddling two nats. With the inner router port forwarding port 1403 from the server. Basically:

    To let me access the services both from the desktop and the laptop. I’d need to have two DNS resolvers, since for the laptop it needs to resolve to the 192.168.0.* address of the homelab router. While for the desktop it needs to resolve directly to the 10.0.0.* address of the server.

    Also, little question. If I do manage to set it up with subdomains. Will all the traffic still go through port 1403? Since the main reason I wanted to setup a proxy was to not turn the homelab’s router into Swiss cheese.

    … The rootCA idea though is pretty good… At least I won’t have Firefox nagging me every time I try to access it.

    (specially with docker containers !)

    Already on it! I’ve made a custom skeleton container image using podman, that when started. It runs a shell script that I customize for each service, while another script gets called via podman exec for all of them by a cronjob to update them. Plus they are all connected to a podman network with manually assigned IPs to let them talk to eachother. Not how you’re supposed to use containers. But hey, it works. Add to that a btrfs cluster, data set to single, metadata set to raid1. So I can lose a disk without losing all of the data. ( they are scrap drives. Storage is prohibitively expensive here) + transparent compression; + cronjob for scrub and decuplication.

    I manage with most of the server. But web stuff just locks me up. :'-)




  • I’m sorry. I forgot to mention it in the post. But the server is not facing the outside. It’s just behind an extra nat to keep my computers separate from the rest of the home. There’s no domain name linking to it. I’m not sure if that impacts using subomains.

    The SSL certificates shouldn’t be a problem since it’s just a self signed certificate, I’m just using SSL as a peace of mind thing.

    I’m sorry if I’m not making sense. It’s the first time I’m working with webservers. And I genuinely have no idea of what I’m doing. Hell. The whole project has basically been a baptism by fire, since it’s my first proper server.








  • I’ll have to check mikupad. For the most part i’ve been using sillytavern with a generic assistant card because it looked like it would allow me plenty of space to tweak stuff. Even if it’s not technically meant for the more traditional assistant use case.

    Thanks for the cheatsheet, it wil come really handy once i manage to set everything up. Most likely i’ll use podman to make a container for each engine.

    As for the hardware side. The thinkcentre arrived today. But the card still has to arrive. Unfortunately i can’t really ask more questions if i can’t set it all up first to see what goes wrong / get a sense of what i Haven’t understood.

    I’ll keep you guys updated with the whole case modding stuff. I think it will be pretty fun to see come along.

    Thanks for everything.



  • Thanks for the advice. I’ll see how mutch i can squeeze out of the new rig. Especially with exl models and different frameworks.

    Gemma 12B is really popular now

    I was already eyeing it. But i remember the context being memory greedy due to being a multimodal model. While Qwen3 was just way out of the steam deck’s capabilities. Now it’s just a matter of assembling the rig and get tinkering.

    Thanks again for the time and the availability :-)


  • at the moment i’m essentially lab ratting the models, i just love to see how far i can push them, both in parameters and in compexity of request. before they break down. plus it was a good excuse to expand my little “homelab” (read: workbench that’s also stuffed with old computers) form just a raspberry pi to something more beefy. as for more “practical” (still mostly to mess around) purposes. i was thinking about making a pseudo-realistic digital radio w/ announcer, using a small model and a TTS model: that is, writing a small summary for the songs in my playlists (or maybe letting the model itself do it, if i manage to give it search capabilites), and letting them shuffle, using the LLM+TTS combo to fake an announcer introducing the songs. i’m quite sure there was already a similar project floating around on github. another option would be implementing it in home assistant via something like willow as a frontend. to have something closer to commercial assistants like alexa, but fully controlled by the user.

    I’ve been following this comm for a bit and there seems like a real committed, knowledgeable base of folks here - the dialog just in this post almost brings a tear to my eye, lol.

    to be honest, this post might have been the most positive interaction i’ve had on the web since the bbs days. i guess the fact the communities are smaller makes it easier to cobble up people that are genuinely interested in sharing and learing about this stuff, same with the homelab community. like comparing a local coffee shop to a starbucks, it just by nature filters for different people :-)