- This topic has 16 replies, 3 voices, and was last updated Jan 21-10:45 pm by BobC.
-
Posts
-
russellb23
I have just moved to antiX from Debian (systemd nay sayer!). I am finding it very comfortable. I have had rust installed through “curl https://sh.rustup.rs -sSf | sh” under ‘root’. I have no issues after exporting the PATH variable from .bash_profile. However, I am encountering ‘bash: /home/rust/.cargo/bin/cargo: Permission denied’. I am not able to think of any clue other than that it is due to permisisons.
My guess:
I have created a separate home partition and mounting it through ‘/etc/fstab’. Could that be a reason? Having said that, My home folder contents permission as follows:
total 20
drwx—— 2 root root 16384 Jan 18 08:38 lost+found
drwxr-xr-x 22 rust rust 4096 Jan 19 19:29 rustCould someone shed some light to troubleshoot/fix this?
Many thanks in advance.
Thanks for indicating the typo. It is indeed ‘rust’ directory and not ‘russellb’.
Here goes my ‘fstab’ entry corresponding to the /home partition, if that could be of any help.
# Mounting home partition
/dev/sda4 /home ext4 rw,async,exec,users 0 0- This topic was modified 4 years, 3 months ago by russellb23. Reason: corrected mistake
entropy
BobC
You are referring to a directory /home/rust but you don’t have that directory, just a directory /home/russellb which is owned by rust and group rust.
Was there some reason you didn’t use the rust language in the repos that comes with automatic install stuff? I don’t know anything about rust, but it sounds like it might be possible that it shouldn’t have been installed as root?
- This reply was modified 4 years, 3 months ago by BobC.
You are referring to a directory /home/rust but you don’t have that directory, just a directory /home/russellb which is owned by rust and group rust.
Was there some reason you didn’t use the rust language in the repos that comes with automatic install stuff? I don’t know anything about rust, but it sounds like it might be possible that it shouldn’t have been installed as root?
Thank you BobC. I have corrected the typo. It should have been ‘rust’ rather than ‘russellb’.
I tried installing rust as ‘root’ just to check am I encountering the same issue. But no. The reason why I am using the way I did install than from the repos is my way of doing can receive periodical updates of rust unlike updates provided through repos. I have had no issues installing and running rust this way under ‘Debian’. I am doubting is this something to do with separate /home partition?
- This reply was modified 4 years, 3 months ago by russellb23. Reason: improved reply content
entropy
When you sign on, do you sign on as rust, then?
My guess would be that if your user id is rust, all should be normal, and if not, I wouldn’t be surprised if there were permission issues. Even being a member of group rust won’t allow you to write anything.
PS: that isn’t /home/rust that I can see, there. If you were to go to that directory in a terminal and type pwd and press enter it will tell you what that directory name is relative to how it is mounted.
- This reply was modified 4 years, 3 months ago by BobC.
Anonymous
symptom: willingness to blindly grant trust to curl | sh
The reason why
symptom: willingness to invite installation of system-wide “stuff” from non-repository 3rd parties
.BobC, bless your heart for caring to assist, butisn’t this situation an example of “just because you can, doesn’t mean you should… and you’re expected to sew your own hide when it eventually (or, in this case, immediately) bites you in the ass”?I thought I did pretty “OK” there. At least I realized and said that he should have installed from the repo if possible and questioned using root authority to install it. He probably understands now why I asked if his user id is rust.
I’ve made mistakes like that in the past, and the best answer I found was to boot from a live USB, save anything I could get to that I needed, reinstall the distro, learn from my goofs, and not make the same mistakes on the next try.
I didn’t intend to “put ya on the spot”, BobC, and I’m not entirely unsympathetic to russel23’s inquiry.
Rust, Go, and nodejs…
…although these are available from debian repositories, they are each a fast-moving/changing target.
Initiates don’t want to “settle for” the currently-packages versions & ya can’t fault them for wanting/needing latest versions, but ultimately it’s a square-peg round-hole game.To accomplish a sane outcome, OP needs to make a choice: Use system-wide debian-stable packaged version (or check for stretch-backports version), or self-install (as non-sudo user) and accept responsibility for the chore of manually performing updating/maintenance.
“Hey, doing that seemed to work without problems when using reg’lar Debian”
Okay, so it seems reasonable to expect that antiX {sudo|envars|.profile} probably CAN be tweaked to match whatever worked in Debian. Rollup yer sleeves, brave trailblazer…I agree. They don’t look like easy choices. If I was going the self install route, I would do it on a test machine to avoid messing up anything important.
Yes, I do sign in as ‘rust’. I am worried now on letting ‘curl and sh’ to use ‘root’ permissions. But also wondering, rust, doesn’t do anything beside downloading binaries of compiler, doc and standard library and export its path to the user PATH variable via setting env variables in .profile/.bash_profile. After hours of examining the issue, finally found that my .bashrc is not being read at the startup! and sourcing so has also no effect on the command prompt (I have a custom set PS1 variable). However, the path is being set properly, if I set that in .bash_profile. When I try to source .bashrc from .bash_profile the shell hangs and I terminate by “Ctrl+c”. Clueless here at this point, as I have not encountered such an issue before. Is re-installing, a good way? Please advice.
I have installed rust the way you’ve mentioned.
- This reply was modified 4 years, 3 months ago by russellb23.
entropy
At this point you answered the questions of the user id and mounting of the drive in the original post, and therefore /home being on a separate drive doesn’t look like it would be an issue to me, which was the question initially I was trying to answer.
When I saw the owner was rust and the directory name was russellb, I thought the system created the russellb directory with that name when installed because your user id was russellb. Now that the directory and user ids are corrected, that causes my theory for why it wasn’t getting access permission to be wrong.
Sorry, I am not good enough with the scripts to help with your follow-on questions. I have fought that kind of thing before with other programs and the easier path is to install something from the repos unless you need the newer stuff badly enough to be willing to fight for it to work like this.
- This reply was modified 4 years, 3 months ago by BobC.
I would first check whether the earlier “adventure” caused root ownership of any of your files:
find /home/russelb -user rootTo fix, if any are found (consider which files have become root-owned,
and which actions during your earlier root login were likely involved, for your future reference):
sudo chown -R russellb:russellb /home/russellbSecond, I would (and suggest you do the same here) revisit the Debian docs regarding dotfiles.
https://wiki.debian.org/DotFiles
https://wiki.debian.org/EnvironmentVariables
The antiX userconfig defaults, as provided in /etc/skel , I don’t recall any “how/when .bashrc is sourced” differences, compared to stock debian. (If you discover/notice any proprietary handling, post back to give future readers a heads-up, eh)The antiX distribution almost certainly prepopulates a different set of userconfig envvars compared to stock debian.
The antiX distribution permits, but does not encourage, “root login” and prepoulates very few of the /root configfiles ~~ expecting/necessitating the “I wannabe root” users to accept responsibility for setting up rootuser config themselves.
Third, a point of confusion:
You mentioned “shell”. Idunno whether the context (of your testing/reporting, above) is a tty console or a terminal emulator.
If it’s a terminal emulator, which program? (glad to hear, but just asking rhetorically)
If roxterm is installed, within its “preferences” you can configure so that it will run a login shell for you by default (if that suits you).
The lxterminal program, I don’t recall that it enables storing that detail as a permanent election. Instead (man lxterminal) we can launch it with commandline option.^—- when you tested changes to your .bashrc et al, maybe you hadn’t logged out/in (nor invoked a new login shell within xyzterm) before testing the result
Hearing that the “shell” hung during your testing leads me to wonder whether you introduced some syntax error(s) while editing your .profile, .bashrc
Rather than immediately contemplating a full reinstall, try replacing (diffing, instead, and selectively merging changes, would probably be more enlightening toward understanding what/where any error(s) had been introduced) your russellb config files with copies from /etc/skel
When experimenting/tinkering with dotfiles, it’s safer to temporarily create an additional user account ~~ mess with the dotfiles, and perform other experimentation while logged in as the throwaway user. Or keep that other account onhand for future testing (a spartan homedir occupies only ~200kb)
Thank you skidoo and BobC. I have made the configuration files to be read on startup (customised couple of dot files, in essence). But the issue still there. As skidoo said, I can go for a re-install but would completely miss the learning process. I have tried installing as sudo. But the problem persists. May be a bug?!
entropy
I have tried installing as sudo. But the problem persists.
Elaborating on why I cringe when reading that (and why I called out “symptom #2” earlier).
“Those who fail to learn from history are destined to repeat it”
Software that is available for download/installation from non-Debian, non-antiX, 3rd parties
might (or might not!) have “best of intentions” but probably has not been tested to ensure
that it will operate properly on THIS operating system.
-=-
Allowing those 3rd parties (via software launched “as root” on your system) to silently push “updates”
onto your system invites disastrous system-wide consequences.v— example (not Rust, but illustrates the risk of potential/inevitable consequences)
https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/
It’s your call, but at this point I would reinstall the operating system and start afresh.
Create a throwaway user account on the system, then login as that user and again install rust.
Take detailed notes describing each of your installation + config steps.
If that attempted rust installation fails, paste your notes into a followup post so that someone else can attempt to confirm the result.I would create a “throwaway system” entirely, but of course I have lots of junker PC’s on hand. I don’t like trusting automatic installs and updates.
If its designed and setup to work on other OS’s but doesn’t work with antiX the path of least hassle is just to put it on one that it has been tested with. I say that because I’m probably not capable of fixing it, either, or if I did, it might take more time than its worth.
You could also try convincing the devs of rust to add in another select that makes running it on antiX an option, like some of the other distro’s listed in the code. They would know how to make it work.
- You must be logged in to reply to this topic.
