Shdwdrgn

joined 1 year ago
[–] Shdwdrgn@mander.xyz 2 points 2 days ago

I've got another ten years or so before I consider retiring, but I'm close enough that this kind of stuff has been on my mind lately. Retirement itself is easy -- just don't ever get sick, have any accidents, or reach the age where the insurance companies decide it's cheaper to pay your family for a wrongful-death suit than to pay for your medical costs. The bastards will choose to murder you every time.

[–] Shdwdrgn@mander.xyz 13 points 2 days ago (4 children)

I've seen the opposite being true... A loved one dies after a lifetime together and the other person no longer has the will to keep going. I think you can keep going as long as you have the desire and your body doesn't give out on you (and your insurance company doesn't deny you a life-saving procedure because they think you're too old and need to die).

[–] Shdwdrgn@mander.xyz 4 points 3 days ago

Sorry, just because you're not capable enough to work with something that wasn't completely fine-tuned for you at the factory doesn't mean many of the rest of us have any problems with these machines. I do manual bed leveling and I can walk away from my printer for a year, turn it on, and pop out as good of print as the previous time it was used. How well does your "real" printer work after a year of neglect and with all the fancy gizmos turned off?

[–] Shdwdrgn@mander.xyz 1 points 4 days ago

Hmm I'm out of ideas then, sorry. Still wouldn't hurt to do a single-layer test print (there are various models that put squares all around the bed) just to see how that's looking. If the issue had been confined to one side or one corner it might have been a mechanical issue, but random areas makes it a lot harder to figure out.

If I remember right, jerk settings should be rather small, like single-digits, but I think calibrating your e-steps will go a lot further for cleaning up the prints.

One other step (and of course I cannot remember what this is called) is related to calibrating the filament 'pressure' along each path. It takes a bit of work to set up but the goal is to create a profile so you get a perfectly consistent amount of filament extruded through the entire length of a path, which compensates for excess amounts at the beginning and end of each path, or too little extrusion through the middle. You might even have to compile your own firmware to enable it if there's not an option in Marlin to turn it on from the software (I was compiling my own anyway for a DIY direct-drive extruder), but it really does make a difference and it's a set-and-forget thing that you only really need to do once.

[–] Shdwdrgn@mander.xyz 2 points 4 days ago (2 children)

Creality bases are notoriously NOT flat although I've heard their quality has improved over the years. I have one of the 1st-gen Ender 3 Pro machines with a terrible dip in the aluminum base. One nice thing about a thicker bed material is that you can use discs of aluminum foil the shim the base. I started with a glass bed and 13 layers of foil to get the glass reasonably flat. I have since moved to 3mm G10 with a PEI sticker which is working pretty well (in case you want to try PEI again). I found some scrap G10 material on ebay and chopped it with a table saw, sanded all the edges, then got a PEI sheet that was 10mm wider than my bed to allow for some slop. Putting down the stickers is a lot easier if you have someone helping you. Then trim the overhang and you're ready to go.

[–] Shdwdrgn@mander.xyz 3 points 4 days ago (2 children)

Yeah that's a pretty tight range for the bed leveling, shouldn't be causing any issues then. OK another possibility here... the failing prints, are they on the left side, right side, one specific corner, or does it tend to move around between prints?

E-steps varies per extruder, not per manufacturer. What they recommend will get you close but there will always be some variance. On my printer Creality recommended a setting of 93 but my measurements put me up around 98, so quite a difference. Are you still using a bowden tube style extruder or did you upgrade to a direct drive? And is your filament spool mounted on top of the printer (if so, what guides have you added for the filament path), or did you move it off to the side?

Erg sorry, jerk is probably what you're looking for here. It's been awhile since I did much printing so I keep confusing the terms.

[–] Shdwdrgn@mander.xyz 4 points 4 days ago (4 children)

Belt tension should be tight enough that you can strum it and hear a tone. It's possible to tighten a belt TOO much, which causes extra stress on the motors. This would result in the motors being physically very hot. However if these were both printed at the same time, that wouldn't be the issue here.

I wonder, how level is your bed? Yes yes, you have a bltouch and all that, but you still need to manually get your bed relatively level. Were these two prints next to each other or on opposite sides of the bed? How did the other prints in the same batch compare (like was there an obvious pattern of failure from one side to the other)? The bad print looks to me like the nozzle is too close, so it might be interesting to see what your first layer looks like in a test across the bed.

Even in the good print there's some blobbing at the end of each path and the main surface should be the same height as the walls around the cutouts. Did you calibrate your E-steps? It kinda looks like you're pushing out a little too much filament. depending on your slicer options, you may also check acceleration to slow down the head at the end of each path, which can help give the whole path a more uniform output.

One other consideration, although not as likely... Warm up the bed and check to see if all areas feel like they're about the same temperature. If part of the heating element went bad then maybe you're over-heating one part to compensate for a lack of heat on the rest of the bed. I only mention this because the bad print looks like it has a slant to it, but that could be an illusion of the photo.

[–] Shdwdrgn@mander.xyz 1 points 4 days ago (1 children)

How much privacy do you have when someone has your account password?

[–] Shdwdrgn@mander.xyz 47 points 4 days ago (4 children)

Gee are you implying that storing passwords in plaintext is a bad thing? /s

[–] Shdwdrgn@mander.xyz 1 points 6 days ago

Who said anything about it being standard? I said I know this CAN happen, and I said it was quite some time ago. We can only hope this insanity isn't still in practice anywhere, but I learned long ago that expecting a corporation to NOT do foolish things will give me the same disappointing results as expecting money to come out of my ass. If there's a manager involved, then something on the tech side is going to get fucked up in the name of saving a buck. Therefore I cannot just assume OP gets a normal NAT address, nor can I assume they have any other firewall type device between them and the internet. With limited data, the best I can do is try and provide some general information, hopefully encourage them to ask more questions or provide more specific information, and just hope they don't have a ridiculously stupid ISP that makes things needlessly complicated.

[–] Shdwdrgn@mander.xyz 1 points 6 days ago

Most of my experience is with iptables, but yeah, I think until you start adding rules nothing is implicitly denied? Once you enable a couple of initial rules then you should have good blocking from the outside while allowing internal traffic to connect freely. It doesn't get in your way until you start using it, but then it doesn't take much to get it going.

[–] Shdwdrgn@mander.xyz 0 points 6 days ago (2 children)

You're right, it doesn't make any sense. And it didn't make any sense at the time either. After setting up the router with a laptop, I moved the connection to the firewall but it refused to connect. When I finally got ahold of tech support they said the connection locks into the first machine that logs in and they had to release it so I could connect the new machine. And just like that the firewall was given a routable IP address and connected to the internet. Stupidest thing I ever heard of, but that's how they were set up. Now this was around 15+ years ago and I would certainly hope nobody is doing that crap today, but apparently that was their brilliant method of limiting how many devices could get online at once.

 

A 1930s-era breakthrough is helping physicists understand how quantum threads could weave together into a holographic space-time fabric.

 

I would love to have them light up like a scoreboard as each representative takes the floor, showing all of the commandments they have broken. If people want so badly to bring religion into politics then lets just show them exactly who they've been voting for. Maybe we can get the news networks in on this too, displaying it on the side of the screen similar to a sporting event.

 

Marjorie Taylor Greene, the bastion of factual information, has once again shown the nature of her character by claiming that peaceful protestors at the Capitol are in fact an "insurrection of terrorists". Don't you see all the violence and mayhem being caused in this video clip? No, me either...

If you want to make such bold comparisons, lets start out by checking how many people are running for their lives or the number of deaths involved between these two events. Or maybe we should be asking why MTG thought it was an "honor" to meet with the people responsible for murder and the attempt to destroy our democracy?

 

I have an annoying problem on my server and google has been of no help. I have two drives mirrored for the OS through mdadm, and I recently replaced them with larger versions through the normal process of replacing one at a time and letting the new drive re-sync, then growing the raids in place. Everything is working as expected, with the exception of systemd... It is filling my logs with messages of timing out while trying to locate both of the old drives that no longer exist. Mdadm itself is perfectly happy with the new storage space and has reported no issues, and since this is a server I can't just blindly reboot it to get systemd to shut the hell up.

So what's the solution here? What can I do to make this error message go away? Thanks.

[Update] Thanks to everyone who made suggestions below, it looks like I finally found the solution in systemctl daemon-reload however there is a lot of other great info provided to help with troubleshooting. I'm still trying to learn the systemd stuff so this has all been greatly appreciated!

 

I've spent the past day working on my newest Poweredge R620 acquisition, and trying to nail down what things I can do without checking. Google has shown me that everyone seems to be having similar issues regardless of brand or model. Gone are the days when a rack server could be fully booted in 90 seconds. A big part of my frustration has been when the USB memory sticks are inserted to get firmware updated before I put this machine in production, easily driving times up to 15-20 minutes just to get to the point where I find out if I have the right combination of BIOS/EUFI boot parameters for each individual drive image.

I currently have this machine down to 6:15 before it starts booting the OS, and a good deal of that time is spent sitting here watching it at the beginning, where it says it's testing memory but in fact hasn't actually started that process yet. It's a mystery what exactly it's even doing.

At this point I've turned off the lifecycle controller scanning for new hardware, no boot processes on the internal SATA or PCI ports, or from the NICs, memory testing disabled... and I've run out of leads. I don't really see anything else available to turn off sensors and such. I mean it's going to be a fixed server running a bunch of VMs so there's no need for additional cards although some day I may increase the RAM, so I don't really need it to scan for future changes at every boot.

Anyway, this all got me thinking... it might be fun to compare notes and see what others have done to improve their boot times, especially if you're also balancing your power usage (since I've read that allowing full CPU power during POST can have a small effect on the time). I'm sure different brands will have different specific techniques, but maybe there's some common areas we can all take advantage of? And sure, ideally our machines would never need to reboot, but many people run machines at home only while being used and deal with this issue daily, or want to get back online as quickly as possible after a power outage, so anything helps...

 

I have been struggling with this for over a month and still keep running into a brick wall. I am building a new firewall which has six network interfaces, and want to rename them to a known order (wan[0-1], and eth[0-3]). Since Bullseye has stopped honoring udev rules, I have created link files under /etc/systemd/network/ for each interface based on their MAC address. The two WAN interfaces seem to be working reliably but they're not actually plugged into anything yet (this may be an important but untested distinction).

What I've found is that I might get the interfaces renamed correctly when logging in from the keyboard, and this continues to work for multiple reboots. However if I SSH into the machine (which of course is my standard method of working on my servers) it seems to destroy systemd's ability to rename the interface on the next boot. I have played around with the order of the link file numbers to ensure the renumbering doesn't have the devices trying to step on each other, but to no avail. Fixing this problem seems to come down to three different solutions...

  • I can simply touch the eth*.link files and I'm back up afte a reboot.
  • Sometimes I have to get more drastic, actually opening and saving each of the files (without making any changes). WHY these two methods give me different results, I cannot say.
  • When nothing else works, I simply rename one or more of the eth*.link files, giving them a different numerical order. So far it doesn't seem to matter which of the files I rename, but systemd sees that something has changed and re-reads them.

Another piece of information I ran across is that systemd does the interface renaming very early in the boot process, even before the filesystems are mounted, and that you need to run update-initramfs -u to create a new initrd.img file for grub. OK, sounds reasonable... however I would expect the boot behavior to be identical every time I reboot the machine, and not randomly stop working after I sign in remotely. I've also found that generating a new initrd.img does no good unless I also touch or change the link files first, so perhaps this is a false lead.

This behavior just completely baffles me. Renaming interfaces based on MAC addresses should be an extremely simple task, and yet systemd is completely failing unless I change the link files every time I remote connect? Surely someone must have found a reliable way to change multiple interface names in the years since Bullseye was released?

Sorry, I know this is a rant against systemd and this whole "predictable" naming scheme, but all of this stuff worked just fine for the last 24 years that I've been running linux servers, it's not something that should require any effort at all to set up. What do I need to change so that systemd does what it is configured to do, and why is something as simple as a remote connection enough to completely break it when I do get it to work? Please help save my sanity!

(I realize essential details are missing, but this post is already way too long -- ask what you need and I shall provide!)

tl;dr -- Systemd fails to rename network interfaces on the next cycle if I SSH in and type 'reboot'

 

Your dreams and imagination evolved as a view into another universe. As with the current beliefs, you cannot decipher technical information -- no words in books, no details of how devices work, so even if you can describe things you see from another place, you could not reproduce a working version.

Now how do you convince others that the things your are seeing are really happening without being labeled insane? And how could you use this information to benefit yourself or others? Take a peek into the multiverse to see how other versions of yourself have solved these problems...

 

I have a self-hosted matrix-synapse server up and running on a Debian linux server, but before I open it up I want to at least get a captcha service in place to reduce spamming. The only module I've seen to handle this function appears to require setting up a Google recaptcha though, however I would prefer to keep all of this entirely self-contained for the privacy of my users. Can anyone recommend a module that allows for a local captcha option? For that matter, can anyone also recommend a captcha system that is pretty straightforward to set up (which is compatible with matrix-synapse) and uses basic preinstalled code bases like perl or python?

And while I'm here, I would also like to provide the option of registering with an email address, but I'm having trouble finding any clear how-to pages on this. Seems like that function might be built directly in to matrix-synapse but I'm just not finding anything helpful. Any suggestions?

I'm fairly new to matrix in general, but I have an initial setup running with the homeserver, Element web page, and an IRC bridge, so if I can just nail down the validation part of registrations I'll have what I think is a good starting point to launch from.

 

I was reading another article which discussed taking measurements of distance stars at 6-month intervals to create a 3D map of their relative positions and direction of movement. This got me to thinking... has anyone proposed 'dropping' stationary satellites outside of Earth's orbital path for continuous monitoring even when our planet is no longer in that spot? It seems like such an arrangement could provide constant monitoring of things that are happening on the far side of the sun, and they could each act as a relay to each other, bringing the signals back around where we could receive them.

It could be fascinating to be able to constantly monitor the path of know comets, or perhaps even to detect large meteors which are safely away from us now but might some day pose a threat. Studies like mapping star positions could rapidly expand with the availability of continuous data feeds, and I'm sure if such a tool were available scientists would come up with a host of new experiments to try.

A couple other things also come to mind. First off is radio telescopes, which can gather more sensitive data by having sensors further apart. Of course in this case they would only be able to peer in two directions unless you set up the array to rotate as a singular ring (which greatly increases the complexity). The other idea was that I know some phenomena are so large that it takes a huge array of telescopes or sensors to even detect them, and something this large could detect truly astounding low frequency events. Throw in some gravity detectors and watch as the waves propagate through our solar system.

I'm just thinking there's a lot of possibilities here and a lot more data could be collected if we could drop four or eight satellites along the way. I would assume the idea has been proposed before, I just didn't know if this is even feasible?

7
submitted 1 year ago* (last edited 1 year ago) by Shdwdrgn@mander.xyz to c/debian@lemmy.ml
 

I've been running systems up to Buster and have always had the 'quiet' option in the grub settings to show the regular service startup messages (the colored ones showing [ok] and such but not all the dmesg stuff). I just upgraded a server to bullseye and there are zero messages being displayed now except an immediate message about not being able to use IRQ 0. Worse, google can't seem to find any information on this. If I remove the quiet option from grub then I see those service messages again, along with all the other stuff I don't need.

What is broken and how do I fix this issue? I assumed it would be safe to upgrade by now but this seems like a pretty big problem if I ever need to troubleshoot a system.

[Edit] In case anyone else finds this post searching for the same issue… Apparently the trick is that now you MUST install plymouth, even on systems that do not have a desktop environment. For whatever reason plymouth has taken over the job of displaying the text startup messages now. Keep your same grub boot parameters (quiet by itself, without the splash option) and you will get the old format of startup messages showing once again. It’s been working fine the old way for 20+ years but hey let’s change something just for the sake of confusing everyone.

[Edit 2] Thanks to marvin below, I now have a final solution that no longer requires plymouth to be installed. Edit /etc/default/grub and add systemd.show_status=true to GRUB_CMDLINE_LINUX_DEFAULT. In my case to full line is:

GRUB_CMDLINE_LINUX_DEFAULT="quiet systemd.show_status=true"

Don't forget to run update-grub after you save your changes.

 

I run my own email server, and a friend received a compromised laptop from work which resulted in a spam attack from Russia yesterday. Turtle settings saved the days with thousands of emails still in the queue when I saw the problem, however it made me realize that everyone with accounts on my server are local, do not travel, and have no requirement to send emails from outside the country.

I found how to use the smtpd_discard_ehlo_keyword_address_maps setting in postfix to block a CIDR list of IPs, then found a maintained list of IPs by country codes on github. Cool so far, and a script to keep my local list updated was easy enough.

Now the question is, what countries should I be blocking? There are plenty of lists of the top hacking sources, but it's hard to block #2 (the US) when that's where I am located. But otherwise, does anyone have a list of countries they outright block from logging on to their servers? From the above google searches I have 17 countries blocked so far, and in the first 30 minutes already stopped login attempts from three of those countries, so it appears to be working.

Of course I could write a script to parse my logs to see who has already made attempts, but that's what services like fail2ban are for, and I'm just wondering if there are any countries in particular I should directly block? My list so far includes the following: ae bg br cn de hk id in ir iq il kp ng ru sa th vn

The question itself may not be that interesting, but I thought at the very least some folks might be interested in my experience and think about doing something similar themselves. I can post more details of what I did if there is any interest.

 

I have Openfire set up with the monitoring service plugin which we have been using with Pidgin on the desktop. One of the things I've noticed is that when I sign in to another computer on the same account, I do not get a history of recent messages (which I thought the monitoring plugin was supposed to provide).

The other thing that doesn't seem to be working right is when I am logged in to two computers simultaneously (using the same account). I expect to see chat messages showing up on BOTH devices so I can go between machines, which again is something I thought the monitoring plug was supposed to provide.

The settings I believe are related are under "Offline messages" which I have set to always store, and retain for up to 30 days. Should I bee looking for anything else?

I have been using Pidgin with XMPP on Google for years, so I know both the XMPP protocol and the Pidgin client are capable of handling this functionality. I've been digging around trying to find a solution, and see a lot of things claiming Pidgin is the culprit here, but those messages are a decade old. I can't seem to find any information on the subject for Openfire newer than about 2016.

I'm hoping there's a setting I need to change or another plugin I need to add to get both of these features working on my server? I really love the software otherwise but this seems like a really basic function that should just work, and I am hoping someone can point me to whatever I'm missing.

view more: next ›