Live data from Hacker News

Unix tricks

mmb.pcb.ub.es

171–180 of 232 posts

Re: Unix tricks

#171

Related earlier discussions: https://news.ycombinator.com/item?id=5022457 https://news.ycombinator.com/item?id=4481234 A pretty good thread on Reddit: http://www.reddit.com/r/linux/comments/mi80x/give_me_that_on... Edit: see https://news.ycombinator.com/item?id=3257393 for a discussion of the above thread. While we're at it, consider using weborf [1] as an alternative to Python's SimpleHTTPServer for simple file shar…

RE: weborf

I will have to look at weborf. I have always wished debian packaged publicfile, similar to djbdns or even dbndns. As it is I am still looking for a "djbdns-like http server" that is apt-get installable and actively maintained.

I will never understand why gnome-user-share depends on apache...

Re: Unix tricks

#172

Feels very outdated. 1. Use zsh, not bash. AUTO_PUSHD, CORRECT_ALL and tons of other options make some tricks redundant. Also, the zle M-n and M-p are more useful than C-r imo. 2. Use tmux, not screen. 3. Use z ( https://github.com/rupa/z ), not j.py. 4. Use cron, not at. Or even systemd timer units, if you're so inclined. 5. Use public-key authentication and keychain, not password-based SSH. 6. Don't send emails fro…

I take it you don't work on many disparate unix systems on a daily basis :) I find most of the time I'm lucky if there's even bash installed on the remote system, it's usually ksh. tmux? way too new. Python? Nope. Perl is the only scripting language I'd wage my balls on beyond awk if I hope to reuse the script again. Sad, but I find this is generally the case in extremely large enterprises where there is a mix of AIX…

Yes, that's exactly why those tricks "feel outdated". It's because they're made to run on systems from the early 2000s

Re: Unix tricks

#173

zsh: setopt extendedglob allows you to use numeric ranges on globbing with : mv p1080 .jpg folderx/ to move p1080100.jpg through p1080300.jpg to a new folder. Still not available on bash or more common shells?

Bash: mv p1080{100..300}.jpg folderx/

TIL, thank you. Here it is from the manpage:

A sequence expression takes the form {x..y[..incr]}, where x and y are either integers or single characters, and incr, an optional increment, is an integer. When integers are supplied, the expression expands to each number between x and y, inclusive. Supplied integers may be pre‐fixed with 0 to force each term to have the same width. When either x or y begins with a zero, the shell attempts to force all generated terms to contain the same number of digits, zero-padding where necessary. When characters are supplied, the expression expands to each character lexicographically between x and y, inclusive. Note that both x and y must be of the same type. When the increment is supplied, it is used as the difference between each term. The default increment is 1 or -1 as appropriate.

Re: Unix tricks

#174
find . -name "*" | xargs grep "hello" 2>/dev/null

Searches all the files in current directory and all subdirectories for files that contain "hello". Add -l option to grep to only display the filenames instead of filename and match.

Re: Unix tricks

#175

'ssh -R 12345:localhost:22 server.com "sleep 1000; exit"' forwards server.com's port 12345 to your local ssh port, even if you machine is not externally visible on the net. This one blew my mind

Better to use, e.g.: ssh -fN -o ServerAliveInterval="240" -R 2222:localhost:22 example.com (And on example.com ssh -p 2222 localhost ) This lets you easily keep the tunnel open long-term. Why? -f Background the ssh process (don't need nohup) -N Don't run any command -o... Make ssh do the work of keeping the session alive forever

This is excellent, thank you!

Re: Unix tricks

#176

Earlier quoted context omitted.

Better to use, e.g.: ssh -fN -o ServerAliveInterval="240" -R 2222:localhost:22 example.com (And on example.com ssh -p 2222 localhost ) This lets you easily keep the tunnel open long-term. Why? -f Background the ssh process (don't need nohup) -N Don't run any command -o... Make ssh do the work of keeping the session alive forever

But the remote host can limit your ServerAliveInterval, however most hosts don't close your session if there is something running. On our clusters this is the only working solution, and I tried both, trust me.

If that's an issue (I've never met a server like that, not to mention one like that and I couldn't change the setting) then wouldn't you rather use this?

  while [ true ]; do sleep 1000; done
Just using:

  sleep 1000; exit
means you can't make new connections after 17 minutes.

Re: Unix tricks

#177

Earlier quoted context omitted.

3) if all the lines of the 10+GB file are actually unique, wouldn't awk keep the whole file in RAM? For files larger than my RAM could this leave my system unresponsive because it's thrashing on swap?

Yes it will, and a bit (read: a lot) more than 10GB as it needs to store the contents of variable x in a hash table (with the corresponding hash key and value of the counter). There's no other magic way it can 'know' whether a particular line has been seen before. You can't rely on hash keys alone as the hashes aren't guaranteed to be unique. For files with relatively few duplicates it's going to be a lot slower than…

The awk run against a file containing almost no duplicates finished after over an hour (compared to 43sec for the sort method).

    $ time awk '!x[$0]++' x.out | wc -l
    16759719

    real    64m41.089s
    user    64m31.970s
    sys     0m3.136s
Peak memory usage (given that it was a 128MB input file) was (pid, rss, vsz, comm):

     8972 1239744 1246488  \_ awk
So > 1GB for a 128MB input file.

Re: Unix tricks

#178
post #169

Feels very outdated. 1. Use zsh, not bash. AUTO_PUSHD, CORRECT_ALL and tons of other options make some tricks redundant. Also, the zle M-n and M-p are more useful than C-r imo. 2. Use tmux, not screen. 3. Use z ( https://github.com/rupa/z ), not j.py. 4. Use cron, not at. Or even systemd timer units, if you're so inclined. 5. Use public-key authentication and keychain, not password-based SSH. 6. Don't send emails fro…

Isn't at just a cron helper for one-off jobs?

Sadly this isn't usually the case

Re: Unix tricks

#179

Earlier quoted context omitted.

But the remote host can limit your ServerAliveInterval, however most hosts don't close your session if there is something running. On our clusters this is the only working solution, and I tried both, trust me.

If that's an issue (I've never met a server like that, not to mention one like that and I couldn't change the setting) then wouldn't you rather use this? while [ true ]; do sleep 1000; done Just using: sleep 1000; exit means you can't make new connections after 17 minutes.

Yes, in fact I use the first one (while true; sleep; ls) but I thought the second is more succint. Anyone interested can make a loop. Please notice that most of the snippets aren't meant to be copied & pasted, but rather analyzed and understood by the user.

Re: Unix tricks

#180
post #118

Earlier quoted context omitted.

No he did mean ssh-keygen which generates a public and private key pair for you. Run ssh-keygen on your local machine and copy the public key to ~/.ssh/authorized_keys and you'll be able to login to the server without a password using ssh -i /path/to/private/key user@host

That approach is insecure, however, because anyone with the private key now has access. When running ssh-keygen, you should add a passphrase to the key, then add the key to ssh-agent so you don't need a password for the account, nor do you need to type the key's passphrase constantly.

Anyone with private key access has control over my user account and has better access than what my private key + passphrase would provide.

I understand layers (probably moreso than most), but this is something that always bothers me a lot from a practicality perspective. My passwords are encrypted at rest via encrypted filesystems. If you are running things on my personal machine as my user account, I'm already being keylogged and/or am executing arbitrary code for you. If I'm logged into somewhere via ssh (hint: I am whenever I have a network connection), you can just scan my ssh config and use my ssh key anyway. From there, you can probably do a lot of other nasty stuff. ssh-agent won't really prevent this. It will prevent the malware from working again when I reboot until I log into another remote host (which I've established I do a lot) where the keylogger now gets me.

It's possible, but extremely unlikely that I have might have completely read-only media. I could be using my TPM device to protect from from booting and executing modified system states. Some of this might prevent you from easily persisting the keylogger threat across reboots. I might also have a module or something that calculate checksums on startup of critical things, have ridiculous anti-exfil outgoing connection policies, etc that prevent all but the most targeted attacks.

I don't have all of that in place. (In particular, to anyone generating a profile for me, I don't build detailed outgoing packet filter rules (you are welcome).) But what I do have in place will probably prevent me from getting my initial passphase keylogged if I used ssh-agent since it's likely (although this isn't strictly necessary) that I'm going to get attacked again after I start logging into remote hosts. So they can't steal my password, but they do have unrestricted access to my user account and the remote users I can log into. That complicates things, but is still a major security failure, to the point where them having the passphrase to my key isn't super important. I mean, in this scenario, they already have the absolute best input vector (a history of me logging in so they can execute attacks at the times I'm supposed to be logging in, as well as direct access to the systems from my ip addresses) to the point where using my ssh key from elsewhere is probably a worse a idea.

Post reply on HN