突突唧之家

The classic Linux way of doing this sort of thing goes something like this:

Create the shared folder:

sudo mkdir /home/shared

Create the new user's group:

sudo addgroup sharespace

Change ownership of the shared folder to the new group:

sudo chown :sharespace /home/shared

Add your desired users to that group:

sudo adduser user1 sharespace

Repeat for all users.

Now you have some decisions to make about what you want those users to be able to do:

1. All group users can add to and delete from the folder and can read and but not write to each others files:

   sudo chmod 0770 /home/shared

2. Same as above but only the owner of the file can delete it:

   sudo chmod 1770 /home/shared

3. All group users can add to and delete from the folder and can read and write to each other's files:

   sudo chmod 2770 /home/shared

4. Same as choice 3 except only the owner of the file can delete it:

   sudo chmod 3770 /home/shared

A 1 in the first position of the chmod command is the sticky bit which prevents deletion of a file to anyone other than the owner.

A 2 in the first position of the chmod command is the setgid bit which forces all new or copied files to have the group of that folder.

A 3 in the first position of the chmod command is the combination of the sticky (1) & setgid (+2) bits.

Finally if you want others outside the group to be able to see the files but not change them change the final 0 in the chmod command to a 5:

sudo chmod 0775 /home/shared

Assuming that you have a program running in the foreground, press Ctrl+Z, then:

[1]+  Stopped                 myprogram
$ disown -h %1
$ bg 1
[1]+ myprogram &
$ logout

If there is only one job, then you don't need to specify the job number. Just use disown -h and bg.

Explanation of the above steps:

You press Ctrl+Z. The system suspends the running program, displays a job number and a "Stopped" message and returns you to a bash prompt.

You type the disown -h %1 command (here, I've used a 1, but you'd use the job number that was displayed in the Stopped message) which marks the job so it ignores the SIGHUP signal (it will not be stopped by logging out).

Next, type the bg command using the same job number; this resumes the running of the program in the background and a message is displayed confirming that.

You can now log out and it will continue running.

If your system uses journalctl then you can easily get the kernel messages (dmesg log) from prior shutdown/crash (in a dmesg -T format) through the following.

Options:

• -k Show kernel messages.
• -b <boot_number> How many reboots ago 0, -1, -2, etc.
• -o short-precise Print in a dmesg -T format.
• -p <priority> Filter by priority output (4 to filter out notice and info).

Commands:

• All boot cycles : journalctl -o short-precise -k -b all
• Current boot : journalctl -o short-precise -k
• Last boot : journalctl -o short-precise -k -b -1
• Two boots prior : journalctl -o short-precise -k -b -2

And so on.

The amount of boots you can look back on can be viewed with the following.

journalctl --list-boot

The output of journalctl --list-boot looks like the following.

1
2
3
4
5
6
7

-6 cc4333602fbd4bbabb0df2df9dd1f0d4 Sun 2016-11-13 08:32:58 JST—Thu 2016-11-17 07:53:59 JST
-5 85dc0d63e6a14b1b9a72424439f2bab4 Fri 2016-11-18 22:46:28 JST—Sat 2016-12-24 02:38:18 JST
-4 8abb8267e06b4c26a2466562f3422394 Sat 2016-12-24 08:10:28 JST—Sun 2017-02-12 12:31:20 JST
-3 a040f5e79a754b2a9055ac2598d430e8 Sun 2017-02-12 12:31:36 JST—Sat 2017-02-18 21:31:04 JST
-2 6c29e3b6f6a14f549f06749f9710e1f2 Sat 2017-02-18 21:31:15 JST—Sat 2017-02-18 22:36:08 JST
-1 42fd465eacd345f7b595069c7a5a14d0 Sat 2017-02-18 22:51:22 JST—Sat 2017-02-18 23:08:30 JST  
 0 26ea10b064ce4559808509dc7f162f07 Sat 2017-02-18 23:09:25 JST—Sun 2017-02-19 00:57:35 JST

Like any other operating system, GNU/Linux has implemented memory management efficiently and even more than that. But if any process is eating away your memory and you want to clear it, Linux provides a way to flush or clear ram cache.

How to Clear Cache in Linux?

Every Linux System has three options to clear cache without interrupting any processes or services.

As the root user:

1. Clear PageCache only.

sync; echo 1 > /proc/sys/vm/drop_caches

2. Clear dentries and inodes.

sync; echo 2 > /proc/sys/vm/drop_caches

3. Clear pagecache, dentries, and inodes.

sync; echo 3 > /proc/sys/vm/drop_caches 

Explanation of the above command

sync will flush the file system buffer. Command Separated by ; run sequentially. The shell waits for each command to terminate before executing the next command in the sequence. As mentioned in the kernel documentation, writing to drop_cache will clean cache without killing any application/service, command echo is doing the job of writing to file.

If you have to clear the disk cache, the first command is safest in enterprise and production as ...echo 1 >... will clear the PageCache only. It is not recommended to use the third option above ...echo 3 >... in production until you know what you are doing, as it will clear pagecache, dentries, and inodes.

How to Clear Swap Space in Linux?

If you want to clear Swap space, you may like to run the below command.

swapoff -a && swapon -a

TL;DR

C-a :sessionname mySessionName

Details

This is,

1. Attach to the session in question.
2. Press Ctrl+A.
3. Type :sessionname mySessionName – yes, the first colon is needed there, no extra spaces.
4. Type Enter.

Renaming without attaching

Screen's -X switch lets you rename a session without attaching it.

screen -S 8890.foo -X sessionname bar

While it might seem like a clear-cut idea, actually there is ambiguity in the meaning of human user. Is a user account deliberately hidden from the login screen because it's used only for specialized purposes (but by humans) a human user? How about the ubuntu user (UID 999) on the live CD? And guest accounts in Ubuntu are created on-the-fly and destroyed after logout; are they human users? More examples could be devised.

Therefore, it's fitting that multiple, non-equivalent answers have been given. Saige Hamblin's solution of running ls /home is what people actually do, and unless you're writing a script, you should probably just use that.

Making ls /home More Robust

But perhaps you have users that have been removed, but whose home directories still exist in /home, and you must avoid listing them. Or maybe for some other reason you must ensure only the entries in /home that correspond to real accounts are listed.

In that case, I suggest passing the names of everything in /home to getent (to retrieve the passwd entries of users with those names), then isolate and display just the username field (with grep, sed, or awk, as per your preference). Any one of these will do:

getent passwd $(ls /home) | grep -o '^[^:]*'

getent passwd $(ls /home) | sed 's/:.*//'

getent passwd $(ls /home) | awk -F: '{print $1}'

This should work well, as you shouldn't have user accounts with whitespace or control characters in their names; cannot, without reconfiguring Ubuntu to allow it; and if you do, you have bigger problems. Thus the usual problems with parsing ls are inapplicable. But even though it's really okay here, if you consider command substitutions with ls aesthetically displeasing or just a bad habit, you may prefer:

getent passwd $(basename -a /home/*) | grep -o '^[^:]*'

getent passwd $(basename -a /home/*) | sed 's/:.*//'

getent passwd $(basename -a /home/*) | awk -F: '{print $1}'

These don't accommodate whitespace or control characters either. I provide them only because $(ls /home) looks wrong even when it is right, and thus rubs many users the wrong way. In most situations, there are real, good reasons to avoid parsing ls, and in those situations parsing basename -a is usually only very slightly less bad. In this situation, however, due to the limitation on what characters may practically occur in usernames, they are both fine.

Install the Quota Tools

1. Install the quota command line tools using apt package manager:

   sudo apt update sudo apt install quota

2. Update the mount options for the filesystem by updating the corresponding entry in /etc/fstab configuration file, using an editor of your choice to:

   # <file system> <mount point> <type> <options> <dump> <pass> /dev/sda /home ext4 defaults,usrquota,grpquota 0 1

The options usrquota and grpquota enables quotas on the filesystem for both users and groups. Ensure that you add the new options separated by a comma and no spaces.

Display members of a group using /etc/group file

Use the grep command as follows (we are looking group named "ftponly"):

grep ftponly /etc/group

To get just a list of all members of a group called "ftponly", type the following awk command:

awk -F':' '/ftponly/{print $4}' /etc/group

Display group memberships for each Linux user

Want to see group memberships for each given USERNAME under Linux? The syntax is as follows for the groups command:

groups your-user-name-here

使用命令

ssh -o ProxyCommand='"C:\Program Files\Git\mingw64\bin\connect.exe" -S 127.0.0.1:1080 %h %p' remoteuser@remotehost

这里 Git 的安装路径和后面的代理自己看着填，不要用相对路径。 参数中 -S 指是 socks 代理，默认是 socks5。如果要使用 HTTP 代理，就写 -H。

With Docker 1.8.1 (August 2015), a docker inspect -f '{{ .Volumes }}' containerid would be empty!

You now need to check Mounts, which is a list of mounted paths like:

1
2
3
4
5
6
7
8
9
10
11
12

{
  "Mounts": [
      {
          "Name": "7ced22ebb63b78823f71cf33f9a7e1915abe4595fcd4f067084f7c4e8cc1afa2",
          "Source": "...",
          "Destination": "...",
          "Driver": "local",
          "Mode": "",
          "RW": true
      }
  ]
}

If you want the path of the first mount (for instance), that would be (using index 0):

docker inspect -f '{{ (index .Mounts 0).Source }}' containerid

Pretty print the whole thing:

docker inspect -f '{{ json .Mounts }}' containerid | python -m json.tool

Or use the jq command:

docker inspect -f '{{ json .Mounts }}' containerid | jq