other people posted:

supervisord

Gyshall posted:

Hi goons - I'm working on a project using Ansible.

Once I'm done setting up my server, I want to take some "screenshots" of the state of the server. These are just commands like top/df/free, but I'd like to capture them including the command and prompt to use in documentation later.

Any tips on how to achieve this? I'm okay just dumping text and then converting it to a screenshot.

Sheep posted:

Trying to do a CentOS install via kickstart on some wonky machines with NVIDIA cards; the text installer (it's all automated) seems to be dying at some point in the install on these machines but I can't tell because the screen is garbled. First time I've seen something like this in text mode.

my bitter bi rival posted:

code:

{
  package => 'package',
  version => '1.0.0',
  commands => [
    ['jslib', '.'],

other people posted:

RHEL 8 Beta is out:

http://redhat.com/en/blog/powering-its-future-while-preserving-present-introducing-red-hat-enterprise-linux-8-beta


Still uses systemd smdh.

Buttcoin purse posted:

Maybe you could try getting it to use a serial console - perhaps it won't make the install work, but you'll at least be able to see where it went wrong?


For the record, that looks like Perl, but since you already have a working solution there's probably no point in suffering through turning it into a slightly smaller one in Perl


This is what I came here and caught up on the last few pages of the thread for. It's true, there's no KDE

I really don't think I want to get to know how GNOME 3 works. Are there any other options that don't involve moving to another distribution?

Using KDE on CentOS in the past meant I didn't always have all the config tools, but I didn't mind running some GNOME/GTK-based config tools under KDE, and I wouldn't mind having to run some of them under some other window manager or desktop environment on CentOS 8.x.

I suppose by the time CentOS 7.x is no longer supported, EPEL might include KDE for CentOS 8.x if I'm lucky. Or maybe IBM will prevent CentOS 8.x somehow.

Salt Fish posted:

What is the execute bit actually used for in linux? I learned in school that it's required to have the system run a binary, but what is the practical use case for it? I was thinking today that a user who can write to any file with the +x bit can just copy binary contents and then run the code they want as if it originally had the +x bit:

[root]# chmod 444 ls
[root]# logout

[idiot]$ ./ls
-bash: ./ls: Permission denied
[idiot]$ touch new_ls
[idiot]$ chmod 744 new_ls
[idiot]$ cat ls > new_ls
[idiot]$ ./new_ls /dev | head -1
autofs

Why isn't the ability to execute system binaries then a property of the user instead of the file? Is there anything different about executing this binary owned by idiot instead of one owned by root?

waffle iron posted:

You can run any ELF executable with ld-linux.so. In Debian it's named something like /lib64/ld-linux-x86-64.so.2 .

RFC2324 posted:

Don't use RHEL/CentOS on the desktop, use Fedora.

Salt Fish posted:

What is the execute bit actually used for in linux? I learned in school that it's required to have the system run a binary, but what is the practical use case for it? I was thinking today that a user who can write to any file with the +x bit can just copy binary contents and then run the code they want as if it originally had the +x bit:

Salt Fish posted:

What is the execute bit actually used for in linux? I learned in school that it's required to have the system run a binary, but what is the practical use case for it? I was thinking today that a user who can write to any file with the +x bit can just copy binary contents and then run the code they want as if it originally had the +x bit:

[root]# chmod 444 ls
[root]# logout

[idiot]$ ./ls
-bash: ./ls: Permission denied
[idiot]$ touch new_ls
[idiot]$ chmod 744 new_ls
[idiot]$ cat ls > new_ls
[idiot]$ ./new_ls /dev | head -1
autofs

Why isn't the ability to execute system binaries then a property of the user instead of the file? Is there anything different about executing this binary owned by idiot instead of one owned by root?

xzzy posted:

code:

# wc -l /proc/mounts
24556 /proc/mounts

Anyone wanna guess what happened.

users with root access and a cron job

Buttcoin purse posted:

I remember when I used to use tcsh, you had to run the command rehash for it to see new binaries in the PATH. Is that still a thing in any shells? I've been using bash for a long time now.

Truga posted:

bash will find new binaries in your path, but if you have something in /usr/local/bin (or another location that's higher priority) and usr/bin, and delete it from local it'll still try to run the now missing one.

i think that's the only case i've found recently where it doesn't just work correctly.

Dominoes posted:

Hey dudes; looking for some advice on what usually comes with Linux. I'm building a frontend framework with Rust, and am working on Windows. I set up the Windows Subsystem for Linux (Ubuntu without GUI inside Windows), and am running into some roadblocks installing Rust packages. Specifically, errors until installing GCC, Build-essential, OpenSSl, libssl etc. I was able to get around these by installing the right packages, either from the errors or Googling, but this would be a frustrating experience for someone not used to Rust. Are these normally included in Linux distros like Ubuntu, and ommitted from the version that comes with Windows? Also, what's the usual convention for calling Python in Linux? I'm running into issues of `python` vs `python3`. Eg in Windows you'd use the `python` command, but in the Subsyst for Linux, `python` runs and old version, and you have to run `python3`.

mystes posted:

If you're installing stuff manually you have to make sure the dependencies are installed yourself; Ubuntu doesn't magically know you want to use rust any more than Cargo will magically know your program's dependencies unless you tell it. You can probably find instructions for what you need installed.

On the other hand, if you install stuff through the package manager it will install the dependencies for you.

Ubuntu uses python3 for python 3 for compatibility reasons.

WSL is basically just normal Ubuntu so you can probably find answers to questions by googling for information about Ubuntu rather than wsl specifically.

Dominoes posted:

Specifically, errors until running sudo apt update, installing GCC, Build-essential, OpenSSl, libssl etc, all which can be done using apt. I got around these by installing the packages, deduced either from the errors or Googling, but this could be a frustrating experience for someone not used to Rust. Are these normally included in Linux distros like Ubuntu, and omitted from the version that comes with Windows?

Also, what's the usual convention for calling python in Linux? Eg in Windows you'd use the `python` command, but in the Subsyst for Linux, the correct command is `python3`. Also running into an issue where you need to run `chmod +x build.sh` on a build script to authorize its execution; is this normal as well? Trying to make this process as painless as possible, and document it. Is it assumed that Linux users would know how to deal with these issues offhand?

Should I include a script that runs apt install for these packages, and chmods the build script?

Dominoes posted:

Thank you! I should clarify that Rust installed and updated without issue, but installing wasm-bindgen-cli with Cargo triggered the errors. The wasm-bindgen guide doesn't mention the dependency issues; it simply instructs to install with Cargo. I'm suspicious most linux-users would be able to immediately recognize how to solve all the errors I mentioned, or already have the right tools installed, but I'm trying to make this as frictionless as possible for a user of uknown experience.

Dominoes posted:

Mr.Radar posted:

The issue I think is you have two different package managers which don't (can't) talk to each other: Cargo and apt-get. apt-get is the Debian/Ubuntu system package manager, which manages the kernel and all the system packages (pretty much everything under /bin, /lib, etc) and knows how all they depend on each other. Cargo is the Rust package manager which knows everything about rust packages and how those depend on each other. The disconnect is that Cargo may install packages that depend on packages managed by apt-get but since they're two separate package managers Cargo can't automatically install those dependencies. The reason Cargo can't just call apt-get is that you may be running it on a system with a different package manager (dnf on RedHat, pacman on Arch, brew on MacOS, etc.) and different system package managers packages also tend to have different names/naming conventions. You'll run into this issue pretty much any time you use a programming language-specific package manager to install a package with system dependencies.

Sheep posted:

It can be normal to need to set the executable flag on things, depending on how you wound up with them. For example if you cloned it out of a git repository and the maintainer had it set as executable, it should get pulled down as executable; if you're just downloading stuff from wherever using wget or something then you may need to set it executable. Most Linux users will see something ending in .sh and know it's runnable though.

I would suggest not including any such system dependency installation in build scripts and instead adding in the documentation what the dependencies are and let the end users make the call, at least as far as system packages go.

Mr.Radar posted:

The issue I think is you have two different package managers which don't (can't) talk to each other: Cargo and apt-get. apt-get is the Debian/Ubuntu system package manager, which manages the kernel and all the system packages (pretty much everything under /bin, /lib, etc) and knows how all they depend on each other. Cargo is the Rust package manager which knows everything about rust packages and how those depend on each other. The disconnect is that Cargo may install packages that depend on packages managed by apt-get but since they're two separate package managers Cargo can't automatically install those dependencies. The reason Cargo can't just call apt-get is that you may be running it on a system with a different package manager (dnf on RedHat, pacman on Arch, brew on MacOS, etc.) and different system package managers packages also tend to have different names/naming conventions. You'll run into this issue pretty much any time you use a programming language-specific package manager to install a package with system dependencies.

minato posted:

Python unfortunately comes in 2 major flavors, not terribly compatible with each other. Everyone should be on Python3 by now, but there's still lots of legacy stuff that relies on Python2. Larger distros like Fedora deal with this by having 2 separate dependency chains for everything (xxxx2 vs xxxx3, so there's python2 and python3, pip-2 and pip-3, etc. They also have another DEB/RPM you can install which sets one or the other to be the "default", so that calling "python" will choose either python2 or python3.

IuniusBrutus posted:

Are there any desktop environments that play well with resolution scaling? Google searches tend to just point to people attempting to state that a 768p TN panel from 1999 is just as good as any modern IPS display and that hiDPI screens don't really matter.

I use a 1080p T480 and 150% scaling is basically perfect - any smaller and this frankly lack-luster screen starts to become hard to look at. Windows 10 handles it well enough enough, but it seems like Linux in general hates anything other than pixel doubling.