How to compile C sources
$
./configure; make; make check; make install
Make sure to check the references in your shell regarding compilation also
The man pages are your friend
How to compile C sources
$
./configure; make; make check; make install
Make sure to check the references in your shell regarding compilation also
The man pages are your friend
How to create a #Linux #bash #script - and what you can do with it. Bash scripts have been around since the humble beginnings of Linux. Here's how to get started with them.
https://www.zdnet.com/article/how-to-create-a-linux-bash-script-and-what-you-can-do-with-it/
Insert Last Argument of Previous Command in #Bash, #Fish, #Zsh
https://ostechnix.com/insert-last-command-argument-bash-fish-zsh/
@cleverboi @rdfhrn @davidgerard I know...
Linux tip: you can edit files from within less by pressing "v". This will launch your default editor.
If you do not have a default editor specified, you can specify one by adding the following lines to your .bashrc:
# set default editor
EDITOR=/usr/bin/vim
Substitute vim for whatever editor you prefer. (Which is obviously vim :)
I experimented with not having persistent shell history, after @simontatham blogged about it.
Good:
- higher threshold for writing long complicated commands
- lower threshold for writing shell scripts instead
Bad:
- writing shell scripts
I've since started experimenting with the Fish shell, and it brings a whole different level to the shell history game. So far I like it.
@davidgerard problem is that I can't rely on #python being available and being allowed to install it!
#TIL #python #shell #bash #makefile
Since a while back, the way "virtual (shell) environment" are implemented for #python has changed.
Tho, on the surface, it did not change tremendously:
python3 -m venv .venv
Will create a directory called .venv
that has the advantageous property of being hidden by default from silver searcher ag, and ripgrep rg, but still reachable with a couple of keystrokes with something along the line of:
ag --python 'def freedom' .venv/
.venv
will contain at least two kind of things that are of interest: executables, and libraries.
You could reach for the ./.venv/bin/python3 -m pip install freedom
but it is prone to error compared to a mere pip3 install freedom
. such as calling ./.venv/bin/python3 -c "import freedom"
. That is quality of life improvement if you "enter" aka. activate the venv... read on...
So, there is couple of files to help with your favourite shell with e.g. source ./.venv/bin/activate.fish
You "enter" an "environment" where the PATH
includes $(pwd)/.venv/bin/
.
The problem I encountered is that source
or even .
does not work all the time, I think because it is a shell language function, like time, and not a command such /usr/bin/true. In particular in a low-tech makefile without m4 or whatever the makefile language is called, a dozen of targets with pseudo shell code, it does not work. The following does not work as expected all the time:
serve:
./.venv/bin/python3 -m freedom
Indeed, if freedom fork a process via @pydoc subprocess or @pydoc multiprocessing (a #POSIX process), and recursively execute a pythhon3, it will not have access to libraries from ./.venv/lib/ because that nested python3 will not be ./.venv/bin/python3 but /usr/bin/python3 because ./.venv/bin/python3 does not include its related library path in sys.path...
In other words, calling executables from ./.venv/bin/ without entering the environment is prone to error.
tl;dr: to stay on the safe side while running a python within a virtualenv called .venv. You need something in the spirit of:
PATH=$(pwd)/.venv/bin/:$PATH` python3 path/to/program.py
Happy Hacking
Okay, so I wanted to share a little incident from a few months back that really hammered home the power of knowing your Linux internals when things go sideways. I got a frantic call, "something weird is going on with our build server, it's acting sluggish and our monitoring is throwing odd network alerts." No fancy EDR on this particular box, just the usual ssh and bash. My heart always sinks a little when it's a Linux box with vague symptoms, because you know it's time to get your hands dirty.
First thing I did, even before reaching for any specific logs, was to get a quick snapshot of the network. Instead of netstat, which honestly feels a bit dated now, I immediately hit ss -tunap. That p is crucial cause it shows you the process and user ID for each connection. What immediately jumped out was an outbound TCP connection on a high port to a sketchy-looking IP, and it was tied to a process that definitely shouldn't have been making external calls. My gut tightened. I quickly followed up with lsof -i just to be super sure no deleted binaries were clinging on to network connections.
With that IP and PID in hand, I moved to process investigation. pstree -ap was my next stop. It showed the suspicious process, and more importantly, its parent. It wasn't a child of systemd or a normal service. It was spawned by a build script that shouldn't have been executing anything like this. That hierarchical view was key. Then, to really understand what this thing was doing, I dared to strace -p <PID>. Watching the system calls unfurl was like watching a movie of its malicious intent: it was reading from /etc/passwd, making connect() calls, and trying to write to some odd /tmp directories. Simultaneously, I checked ls -l /proc/<PID>/exe to confirm the actual binary path (it was indeed in /tmp) and /proc/<PID>/cwd to see its working directory. No doubt, this was a rogue process.
Knowing it was a fresh infection, I immediately shifted to the filesystem. My go-to is always find / -type f -newermt '2 days ago' -print0 | xargs -0 ls -latr. This quickly pulls up any files modified in the last 48 hours, sorted by modification time. It's often where you find dropped payloads, modified configuration files, or suspicious scripts. Sure enough, there were a few more binaries in /tmp and even a suspicious .sh script in a developer's home directory. I also scanned for SUID/SGID binaries with find / -perm /6000 just in case they'd dropped something for privilege escalation. And while stat's timestamps can be tampered with, I always glance at atime, mtime, and ctime on suspicious files; sometimes, a subtle mismatch offers a tiny clue if the attacker wasn't meticulous.
The final piece of the puzzle, and often the trickiest, is persistence. I checked the usual suspects: crontab -l for root and every other user account I could find. Then I cast a wider net with grep -r "suspect_domain_or_ip" /etc/cron.* /etc/systemd/system/ /etc/rc.d/ and similar common boot directories. Sure enough, a new systemd timer unit had been added that was scheduled to execute the /tmp binary periodically. Finally, I didn't forget the user dotfiles (~/.bashrc, ~/.profile, etc.). It’s surprising how often an attacker will drop a malicious alias or command in there, assuming you won't dig deep into a developer's setup.
Long story short, we quickly identified the ingress vector, isolated the compromise, and cleaned up the persistence. But what really stuck with me is how quickly you can triage and understand an incident if you're comfortable with these fundamental Linux commands. There's no substitute for getting your hands dirty and really understanding what strace is showing you or why ss is superior to netstat in a high-pressure situation. These tools are your best friends in a firefight.
А какой там аналог **/*.ext
для условно бесконечной глубины рекурсии?
simple commandline flag parsing template (getopts without values):
https://www.draketo.de/software/shell-tricks#commandline-options-flag-template
Nouvel article sur mon blog à propos de #tmux avec un peu de #bash dedans
https://xieme-art.org/post/ma-configuration-tmux-raccourcis-clavier-et-gestion-des-sessions/
In a GNU/Linux shell, The `[` is just a regular command and `]` is just the last argument of `[`.
ls -la '/usr/bin/['
#Linux #Unix #bash #sh
https://stackoverflow.com/a/47576482/3451846
If `.` is the current folder and `..` is the parent folder, why isn't `...` the grandparent folder? `cd ...` would save me keystrokes.
#bash #PowerShell
$ last | lolcat
I Love the colourful output of lolcat
Γκερδαμε αδερφια, η αναγνωριση ερχεται απο τα εξωτερικα, γραφουνε για το παιχνιδι που εφτιαξα:
https://itsfoss.com/sausage/
Repo link:
https://gitlab.com/christosangel/sausage
#linux #terminal #tui #bash
On FreeBSD, which interactive shell do you primarily use for your non-root user?
If "other", perhaps leave a comment about which shell it is.