• 0 Posts
  • 9 Comments
Joined 1 year ago
cake
Cake day: July 24th, 2023

help-circle

  • Macros@discuss.tchncs.detolinuxmemes@lemmy.worldOh, come on!
    link
    fedilink
    arrow-up
    31
    arrow-down
    2
    ·
    2 months ago

    I don’t know why such answers get so many upvotes.

    The real answer is: Right-click -> Pin to Taskbar. (In sane desktop environments like KDE. If you choose to install Fancy DE Alpha 0.0.2, you know what you got into!)

    Yeah we are in a meme community, still I like my memes based on reality, makes them way funnier.

    (Also having a standard place for documentation for everything is a blessing!)






  • But in the details this attack is not that bad. E.g. NordVPN and I guess also other VPNs use firewall rules to drop traffic on normal network interfaces.

    Their side channel is still routing traffic away from the VPN channel. Then they can observe that there is no traffic and guess that the user either didn’t make requests in that moment or that he wanted to visit a website in the range covered by the route. They can not spy on the traffic.

    Also you can not quickly move into a network and apply this attack, as DHCP leases usually last 1 day or at least 1 hour. Only when they expire you can apply the attack (or you force the user to drop from the network, which is easy if they are using WPA2, but only possible by blocking the wifi signal if they are using WPA3)

    It is a serious issue and should be mitigated, but not as huge as news articles make it.


  • I am a sysadmin and believe me when I say that happens. Mostly due to updates. Within that updates that just plainly break things. E.g. deleting the users files. Or other updates which only break some PCs. (those are fun to diagnose) E.g. if the recovery partiton created by its own installer is suddenly to small. and I also had it more than a few times that Windows pulled in a driver “update” which broke things. One time it even tried to apply the wrong driver! I have now disabled all driver updates trough windows on all PCs I manage. Rarely PCs also just suddenly refuse to boot, being caught in a recovery loop. After trying two times for hours to find the reason and only one success I don’t care anymore and just restore a working backup in that case. Mind that (nearly) all users do not have admin rights.

    On Linux? I had it that release upgrades broke things, but only once several years ago on the PCs where I wait till the official release is made. On my own ones I am often to feature hungry to wait until after the beta, and I know I can fix things. I had one 12 year old PC where X11+KDE got unstable after a release upgrade, thankfully a switch to Wayland solved this. Besides that? Never had any issue I didn’t cause myself and never had a running system which suddenly broke. Granted I do not administer as many Linux PCs as Windows ones. But there are a few, some of them also in the hands of users.


  • Run sudo apt dist-upgrade -y right after an upgrade to the Kubuntu 24.04 beta on a semi production system.

    This is right after the xz thing happened. Also while Ubuntu made the t64 migration (Replaced packages with a 32 time variable with a 64 bit one, the packages are renamed. E.g. lib2geom1.2.0 to lib2geom1.2.0t64)

    Packages based on the compromised xz had been removed from the repositories, but I already had some newer ones installed which where dependent on them. Also they already wanted the packages with the t64 addition, which by now where nowhere present in the system.

    So dist-upgrade did what it could to upgrade 5 packages and bring the system into a consistent state: It uninstalled half of the system including some somewhat essential packages.

    I noticed one of them scrolling by and hit CTRL+C. Afterwards I had the choice of saving the data and restoring from a backup a few weeks ago, or to patch it up by hand. So I did the second and created transitional packages like an empty lib2geom1.2.0t64 which depends on lib2geom1.2.0 which was in the repositories back then. 20 of these later I could install packages to get the GUI somewhat working and now weeks later all the t64 migrations are back in the repos and the system is fully functional again :)

    Lessons learned:

    • Be very careful with dist-upgrade
    • Manually trigger a backup before a release upgrade

    In now upgrade with
    sudo apt-get update && sudo apt-get upgrade -yV && read -p "Flatpak Update? (yj/n): " choice && [[ $choice = [YyJj] ]] && sudo flatpak update --noninteractive
    and equivs-build ( sudo apt install equivs) came in really handy in building the transitional packages fast.