Acacia | Random question: Would it be a dumb idea to create a LVM volume group from a disk's partition + the entirety of another disk? | 01:17 |
---|---|---|
Acacia | use case is I'm going to have my home partition span most of one disk, aswell as all of a different disk I'm installing | 01:17 |
PinkBellyNagger | fuck systemd this shit is ruining my life | 13:49 |
PinkBellyNagger | It makes me nervious even thinking about restarting my server (which is long overdue a reboot already) | 13:54 |
jonadab | Why on earth did you install systemd on a *server*? | 13:55 |
jonadab | I wouldn't even install that malarke on a laptop. | 13:55 |
sixwheeledbeast^ | Systemd needs regular reboots to avoid the seemingly constant hack patching | 13:56 |
jonadab | defenestration, is what systemd needs. | 13:57 |
djph | jonadab: funny, thats the same thing Windoes servers need. | 13:58 |
PinkBellyNagger | I'm moving to devuan once I have time to test it, run my use cases etc | 14:04 |
MinceR | just treat it like windows: install once, make image, reboot when it wants/needs to, reinstall from image when it breaks | 16:00 |
KatolaZ | AntoFox: you here? | 17:09 |
AntoFox | KatolaZ: hey | 17:56 |
AntoFox | yep | 17:56 |
woll | Hi | 18:52 |
gnarface | hi | 18:52 |
woll | I copied a folder to /opt using "sudo cp", but I can only acess that folder as root. | 18:53 |
woll | My user is already in the sudoer group. | 18:53 |
amesser | do you need read or read/write access | 18:54 |
KatolaZ | woll: cp -a | 18:54 |
rwp | sudo cp and sudo cp -a will copy the source permissions too. If you as a normal user can't read the original then you won't be able to read the copy either. | 18:59 |
gnarface | rwp: presumably he had access to it before, or he wouldn't be asking the question, but that's a good point | 19:00 |
gnarface | well, that cp -a will, anyway | 19:00 |
rwp | So will the default cp without any options too. Try a test! sudo cp /etc/shadow /opt/ and then look at the result. Be sure to clean up after the test. | 19:01 |
gnarface | sudo cp will actually not, i don't think. the permissions should be clamped by umask in that case, and ownership would be changed to root, which combined with the default umask would remove everyone's access but root (as "sudoers" isn't a user) | 19:01 |
rwp | the umask only affects the mode bits. Not the user and group. | 19:02 |
gnarface | right, but that's irrelevant to my statement | 19:02 |
rwp | But the complaint was that after a sudo cp woll could only "access that folder as root". | 19:03 |
rwp | I think that anything that requires that is fair game then. :-) | 19:03 |
woll | "cp -a" copied the permissions too. But I still can't acess it with my regular user. | 19:04 |
gnarface | woll: well do you have read permission on the parent directory? you would naturally need that too | 19:04 |
KatolaZ | woll: it means your regular user didn't have access before either | 19:04 |
rwp | What is it that you are trying to do woll? I mean the overall thing. Not the low level copy thing. Why do you want to do this copy? | 19:04 |
KatolaZ | you also need x on dirs | 19:04 |
gnarface | yea, true but only to list, not to access if you know the path directly | 19:05 |
amesser | I'm currently restoring/rescuing data from an (very) old Fujitsu Siemens TX200 S4 Server. No further use for it (Tower, Dual Xeon E5430, 5x 2,5" 140GB SAS Disk at PCIe HW-Raid Controller, 3GB ECC Ram, Dual Hotwsap Powersupply). Anyone interessted in parts of it? (total weight of the whole box is arround 30 Kg) | 19:06 |
woll | I have a jar file and a simple bash script to run it. The goal is to create a folder in /opt to store them, and create a launcher. | 19:06 |
woll | I had acess to the folder before, but I accidently deleted it. Now I only have the one with root permission. | 19:07 |
amesser | woll i that case would make the folder/files owned by root, group root and give read/execute permissions for all | 19:07 |
rwp | Thanks for that! It helps. If you are copying a directory (you called it a folder, we call those directories) then you need to change the user, group, and permissions so you can access it. | 19:07 |
amesser | chmod -R root:root /opt/<folder-name> | 19:08 |
amesser | ahh | 19:08 |
amesser | wrong: correct: chown -R root:root | 19:08 |
KatolaZ | amesser: woll wants access for his/her user | 19:08 |
KatolaZ | not for root | 19:08 |
rwp | sudo chown -R woll:woll /opt/yourdirectory ; sudo chmod -R u+rw,g+rw,o+r,a+X /opt/yourdirectory | 19:08 |
KatolaZ | IIUC | 19:08 |
amesser | then chmod -R a+rX /opt/<folder> | 19:08 |
gnarface | do you actually want X not x? | 19:09 |
amesser | Katolaz: yep, but as long as only execute and read is required, i tend to have files under /opt owned by root | 19:10 |
rwp | X is a very special permission action. Best to read the real docs so I don't describe it incorrectly. | 19:10 |
gnarface | woll: yea i guess it depends on if you want the user to be able to change stuff or just run the program... | 19:10 |
KatolaZ | amesser: we seem to be a whole mile behind the issue of having all the files under /opt belonging to root here :) | 19:10 |
amesser | ok | 19:11 |
rwp | https://www.gnu.org/software/coreutils/manual/html_node/Conditional-Executability.html#Conditional-Executability | 19:11 |
gnarface | woll: typically the user would have the ability to run programs from there but not change anything - you can do whatever you want but there are security risks for some choices | 19:11 |
rwp | The rationale is that it sets execute permission only on previously executable files and also on previously executable directories but does not turn everything executable. | 19:12 |
gnarface | oh, that's handy | 19:13 |
woll | gnarface: Exactly. I prefer for it to read and execute files. | 19:13 |
bahumbedbug | o_O who puts user files under /opt | 19:13 |
KatolaZ | bahumbedbug: please | 19:14 |
bahumbedbug | ? | 19:14 |
KatolaZ | woll: is there a specific reason why you want that file under /opt? | 19:14 |
bahumbedbug | /last woll | 19:14 |
bahumbedbug | akc | 19:14 |
KatolaZ | bahumbedbug: woll has problems with setting permissions (chmod) so policy considerations are two meters above the problem here... ;) | 19:15 |
rwp | Since /opt, and /srv, and some of those others are not described by the FHS then the local admin is allowed to do anything they wish there. Just like /usr/local. It is often useful to put NPC user data such as www-data and similar things there. | 19:15 |
bahumbedbug | still confused, who would put user files under /opt though.. that is pretty silly.. almost as bad as /srv | 19:16 |
gnarface | hmmm. why do i keep remembering /opt being in the debian FHS? | 19:16 |
rwp | For all I know it is a minecraft server installed there. (shrug) | 19:16 |
gnarface | oh, because it is https://wiki.debian.org/FilesystemHierarchyStandard | 19:16 |
woll | KatolaZ: Organization. | 19:17 |
bahumbedbug | /opt goes back a long, long time .. wouldn't surprise me if debian got it wrong too. | 19:17 |
rwp | Is it? But no packages are allowed to install files there. | 19:17 |
gnarface | rwp: yes, it's specifically reserved for vendor stuff (extra-distro packages) | 19:17 |
KatolaZ | woll: by policy, normally any file under /opt belongs to root or to a system user | 19:17 |
bahumbedbug | /opt is optional software not part of the base distro/os, at least it was supposed to be. Whatever the hell debian does is their own doing | 19:17 |
KatolaZ | bahumbedbug: this is the case | 19:18 |
KatolaZ | it's a jar | 19:18 |
KatolaZ | that woll wants to launch from the desktop | 19:18 |
KatolaZ | it's third-party software | 19:18 |
KatolaZ | so it might well go under /opt/PACKAGENAME/ | 19:18 |
bahumbedbug | is it part of a package ? | 19:18 |
KatolaZ | it's a jar | 19:18 |
rwp | In the traditional unix systems such as HP-UX one often finds packaged software that installs there. I think that is why the structure was propagated as optional into GNU/Linux distros too. | 19:18 |
KatolaZ | it's a java application | 19:19 |
KatolaZ | from somewhere | 19:19 |
KatolaZ | doesn't matter IMHO | 19:19 |
KatolaZ | it would be good to have it under /opt/APPNAME/ | 19:19 |
bahumbedbug | kinda does | 19:19 |
woll | I run that "chmod -R a+rX /opt/<folder>" command, this gave me the permissions, even after copying it to "/opt". | 19:20 |
gnarface | the winehq packages do already follow it that way, as /opt/APPNAME/... | 19:20 |
woll | KatolaZ: Indeed. A proper directory makes it even more tidy. | 19:20 |
bahumbedbug | way I look at it is basically anything that can be installed standalone can go into /opt. qt and wine for example. Symlinks can be used after | 19:22 |
gnarface | i think there might be some precedent for /opt/VENDOR/APPNAME/ | 19:22 |
bahumbedbug | indeed there is. | 19:22 |
bahumbedbug | you can think of /opt as /usr or /usr/local from a linker perspective but it's not required (architecture directory convention for example doesn't need to be the same). | 19:23 |
KatolaZ | there are many cases like that, indeed | 19:24 |
KatolaZ | stuff like matlab or mathematica, for instance, normally tries to go under /opt/VENDOR/APPNAME | 19:24 |
woll | I have intelliJ installed. It also goes under /opt. | 19:25 |
bahumbedbug | a lot of software that doesn't have formal packages does to not clobber existing systems | 19:27 |
bahumbedbug | I wouldn't expect a distro provided release to do so | 19:28 |
KatolaZ | bahumbedbug: definitely | 19:28 |
KatolaZ | that's the same reason why stuff under /opt normally belongs to root or to a system used | 19:29 |
KatolaZ | ~user | 19:29 |
bahumbedbug | aye | 19:29 |
woll | Is there a way to set the permissions of that user to any file or folder he copies from /opt to /home? | 19:30 |
woll | Just to skip the command of granting permissions. | 19:31 |
bahumbedbug | umask | 19:31 |
gnarface | for normal users, when they copy the file from /opt to anywhere, the default ownership should be themselves | 19:33 |
woll | gnarface: Even if I run it with a "sudo cp"? | 19:34 |
gnarface | woll: no, because by default sudo is doing that as root | 19:35 |
gnarface | that's the point of sudo | 19:35 |
gnarface | but if the user can read a file, they don't need sudo to make a copy of it | 19:35 |
woll | Understood, thanks. | 19:36 |
gnarface | no problem | 19:36 |
redrick | bahumbedbug: Funny thing, I have /opt -> /usr/local/opt on my systems, because I consider /opt redundant to /usr/local and basically a dumb proprietary-software idea. | 21:05 |
MinceR | funny, /opt holds free software just fine over here | 21:10 |
rwp | The /opt is really just another abstraction layer in the software. It's just another layer. | 21:34 |
rwp | Just remember that there isn't any problem in software that can't be solved by adding another layer. Except the problem of having too many layers. | 21:34 |
redrick | MinceR: /opt's ability to hold free software doesn't change proprietary code having been the reason for its adoption, which was the minor portion of my point, the major one being it being redundant as well. | 22:07 |
MinceR | i prefer not to mix different packages with each other and /opt is a pretty nice tool for avoiding that | 22:40 |
redrick | If there's a reason a symlink to directory /usr/local/opt doesn't do that exactly as /opt does, it's not evident to this easily confused sysadmin. Are you perhaps just wanting to argue? #ArgumentClinic beckons. ;-> | 22:46 |
MinceR | i'm not sure what the point of it is | 22:58 |
redrick | OK, I'll add that to life's small disappointments. | 23:02 |
MinceR | ok | 23:25 |
redrick | Syminking /opt to /usr/local/opt gets it off the root fs and places IMO like with like. | 23:54 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!