I just downloaded and installed Kali Linux on my MacBook Pro (dual boot) to mess around with penetration testing - I have experience with aircrack-ng, but it was a while ago (and I was at least unaware of the distributions geared towards penetration testing). Finally got everything up and running, and customized the way I want - I tried to run the basic injection test aireplay-ng -9 wlan0 in the terminal and I get command not found when I try it as admin. The weird thing is it seems to work as root (I didn't try running the test - I just typed in aireplay-ng to see if it recognized the command, and it does). I don't think it is a PATH problem, but I added /usr/sbin/aireplay-ng to /root/.bashrc like this (just incase):
PATH=~/usr/sbin/aireplay-ng:$PATH
I don't think it is the path, because - as you can see, aireplay-ng is located in /usr/sbin/ which is already part of my PATH variable (noticeable when I execute echo $PATH).
The odd part is - when I log in as root, it seems to work - I didn't actually run the test as root (probably not the best idea), but I did type in aireplay-ng to see if the command was recognized, and it was. Not sure if a symlink would help - but I'm not going to try anything until I get a response.
Just trying to get the aireplay-ng command recognized. Thanks in advance. (I posted this on superuser too - but it seems like people are more active on stack).
Turns out I think you need root access for aireplay-ng (probably for the whole aircrack-ng suite too).
Related
I'm following this article as a practice.
And stuck with
cat .config/solana/devnet.json
I realize that windows OS doesn't have cat so I tried
type ~/.config/solana/devnet.json
that result in
The syntax of the command is incorrect.
so I try again with
type "~/.config/solana/devnet.json"
and this time, it leads to
The system cannot find the file specified.
It's kind of surprise me so I browse that directory(C:\Users\my-name\.config\solana) and found devnet.json is truly not there.
My questions are where could this file be? Or which step I might do wrong so the file was not generated? I check the result message of each step, things look fine...
It turns out since I didn't change the working directory so the devnet.json is saved in C:\Windows\System32\~\.config\solana
Got the same problem
It seems that there is no devnet.json file created but the devnet wallet works successfully
you may download git bash on your windows machine and can simply use cat and all bash commands after?
You're following Linux instructions which are not 100% compatible with your Windows OS. ~ is alias for home directory in Linux and it doesn't work in Windows where ~ is a normal char. That led to you the initial confusion. Also other differences like type / cat. On Windows use full path to your home directory (usually something like C:\Users..., etc.). So your key-gen command can look like something like this
solana-keygen new --outfile C:/Users/hsiao/keys/devnet.json
Then you can use
solana config --keypair C:/Users/hsiao/keys/devnet.json
and be happy ever after!
I've noticed recently weird behaviour of bash. It was reporting non-existing preexec_set_exit command or function. Small investigation showed that when I'm being logged through ssh PROMPT_COMMAND variable is set to following value:
PROMPT_COMMAND=preexec_set_exit;preexec_invoke_cmd
It happens only on ssh, even when I'm logging into localhost.
Tried to grep through all files in ~/ and in /etc but no luck
I was installing and testing a while ago some tools and hacks from the net but can't remember what could cause the issue. Any ideas where this comes from or how to debug (and remove) it?
OK. Never mind. I've got it.
If anyone wants to know what happens when you're sshing into your box, and what helped me - it was:
ssh host -t "bash --verbose --login"
Which in my case showed this:
. /usr/share/undistract-me/long-running.bash
Which declares several hooks for handling long running commands using tricks like this one.
And that solves my worries about being hacked.
I am a linux noob trying to setup openbox on an arch linux base. I am trying to get it as lightweight as possible in terms of resources used.
My final plan is to use openbox, with tint1 and conky.
however I am having an issue getting openbox to start. I have followed numerous guides and am struggling to figure out the problem.
I have so far installed the following (and done this config)
openbox (installed default option with the extras asked for)
create ~/.conifg/openbox
copied, rc.xml, menu.xml, autostart, environment to the above location
pyxdg
xorg-xinit
xorg-server
this didn't work so I the installed the full
xorg
still nothing, although when I try to run startx the screen goes black for a second as though it is trying, but then goes back to text mode saying it has failed.
I have had a look at the attached log file, but I don't know enough to be able to interpret it properly.
log file: https://www.dropbox.com/s/r76fowkooi822y9/Xorg.log?dl=0
I would appreciate any assistance.
Thanks
Steve
still nothing, although when I try to run startx the screen goes black for a second as though it is trying, but then goes back to text mode saying it has failed.
what is it saying?
There is only one error: (EE) open /dev/fb0: Permission denied, try starting your environment with the same configuration as root - just to see if it works. Maybe its a problem related to rootless X.
Have you configured/checked your installation (xserver, graphics driver, xinit config) using the following guides?
https://wiki.archlinux.org/index.php/xorg
https://wiki.archlinux.org/index.php/xinitrc
Try to start a minimal X (As described in the xinitrc article) to see if your xserver and graphics driver is working correctly.
Running Ubuntu 14.04, and I have a script that is being run automatically when I boot the machine. For the life of me, I can't remember how or where I did this.
I already checked:
upstart (which doesn't seem to be available here, anyway)
/etc/rc.local
crontab (with #reboot)
/etc/init
/etc/init.d
.config/autostart (doesn't exist btw)
It's a script of my own, so it's not some kind of malicious virus or malware or anything. I just can't remember how I did this, and would like to know.
It has a distinct name, e.g. like ~/MyScriptXYZ.sh so I could search for that, IF I know how or where..?? (I'm a novice linux user)
A few other places you can look:
crontab -e as your own user and as root (local user crontab)
/etc/profile.d/ or /etc/profile
~/.profile
~/.bashrc
The last ditch attempt you can do is to cd / && grep -R "MyScriptXYZ" as root - this will take a while but will search all files on your computer for that reference :)
So I stumbled across this question and I managed to solve it for myself:
I was using Ubuntu (chroot) through the Linux Deploy Android app and I also couldn't find it. So to make the answer complete: Use pstree to locate and trace what is currently running and see where it's originating from.
Following Basile Starynkevitch's advice I managed to solve it by going to:
/home/[user]/.config/lxsession/LXDE/autostart and find it the code I added a while ago.
Just got emacs24.4 compiled and try to run it in daemon mode.
OS: Ubuntu 14.04
In terminal:
When I run it with "emacs -Q --daemon" everything works fine. But when I run it with "emacs --daemon", it doesn't return to shell (emacs24.3 works fine).
Is there any easy way to debug what's wrong in the init file which works fine for 24.3 but not 24.4?
Recursively bisect your init file, to find out what the culprit code is. You can do this by commenting out 1/2 of it, then 3/4 of it, then 7/8, then 15/16,... IOW, a binary search - it is very quick.
You can use command comment-region to comment or (with C-u) to uncomment the region. (I bind it to C-x C-;.)
Then remember this answer. It applies to any problem introduced by your init file.
Everything in your question that has to do with "Emacs 24.4" and "daemon" and "shell" only becomes relevant (if it is) after you have narrowed things down to find just what code is responsible for introducing the bad behavior.Once you do that, if the solution to what remains is not obvious, then please post another (new) question here that covers the relevant info, whether it be Emacs 24.4, shell, daemon, or whatever.