Batch 2: Migrate technical references from Job to Resources
- Move 5 technical reference files to 300-resources/Development/ - curl POST examples → Tools/curl-post-examples.md - sudo blocking guide → Linux/sudo-command-blocking.md - Gradle cheatsheet → Tools/gradle-cheatsheet.md - Filesystem limitations → Linux/filesystem-limitations.md - IPA server installation → Linux/ipa-server-installation.md - Job area now focuses on career development content - Created Tools/ and Linux/ subdirectories in Development/ (vault changes by Claude Code)
This commit is contained in:
@@ -0,0 +1,15 @@
|
||||
Fundamental rules for for Universal Naming Convention (UNC),which enable applications to create and process valid names for files and directories, regardless of the file system:
|
||||
|
||||
Following reserved characters:
|
||||
```
|
||||
< (less than)
|
||||
> (greater than)
|
||||
: (colon)
|
||||
" (double quote)
|
||||
/ (forward slash)
|
||||
\ (backslash)
|
||||
| (vertical bar or pipe)
|
||||
? (question mark)
|
||||
* (asterisk)
|
||||
```
|
||||
Use any character in the current code page for a name, including Unicode characters and characters in the extended character set (128–255),
|
||||
@@ -0,0 +1,9 @@
|
||||
```bash
|
||||
|
||||
sudo ipa-server-install --realm=INT.IT2000.COM.CN --domain=int.it2000.com.cn --ds-password=admingzzn --admin-password=admingzzn --hostname=ipa.int.it2000.com.cn --ip-address=10.16.67.98 --setup-dns
|
||||
|
||||
sudo firewall-cmd --add-service={http,https,dns,ntp,freeipa-ldap,freeipa-ldaps} --permanent
|
||||
|
||||
sudo firewall-cmd --reload
|
||||
|
||||
```
|
||||
@@ -0,0 +1,23 @@
|
||||
If your user is called `user` and your host is called you could add these lines to `/etc/sudoers`:
|
||||
|
||||
```
|
||||
user = (root) NOPASSWD: /sbin/shutdown
|
||||
user = (root) NOPASSWD: /sbin/reboot
|
||||
```
|
||||
|
||||
This will allow the user `user` to run the desired commands without entering a password. All other sudoed commands will still require a password.
|
||||
|
||||
The commands specified in the `sudoers` file _must_ be fully qualified (i.e. using the absolute path to the command to run)
|
||||
|
||||
If the command ends with a trailing `/` character and points to a directory, the user will be able to run any command in that directory (but not in any sub-directories therein). In the following example, the user `user` can run any command in the directory `/home/someuser/bin/`:
|
||||
|
||||
```
|
||||
user = (root) NOPASSWD: /home/someuser/bin/
|
||||
```
|
||||
|
||||
As an alternative to editing the `/etc/sudoers` file, you could add the two lines to a new file in `/etc/sudoers.d` e.g. `/etc/sudoers.d/shutdown`. This is an elegant way of separating different changes to the `sudo` rights and also leaves the original `sudoers` file untouched for easier upgrades.
|
||||
|
||||
*visudo can be used to edit those files too, this prevent error that could lock you out of the system*
|
||||
```
|
||||
sudo visudo -f /etc/sudoers.d/shutdown
|
||||
```
|
||||
@@ -0,0 +1,42 @@
|
||||
|
||||
|
||||
<h2>Common Options</h2>
|
||||
<div>-#, --progress-bar Make curl display a simple progress bar instead of the more informational standard meter.</div>
|
||||
<div>-b, --cookie <name=data> Supply cookie with request. If no =, then specifies the cookie file to use (see -c).</div>
|
||||
<div>-c, --cookie-jar <file name> File to save response cookies to.</div>
|
||||
<div>-d, --data <data> Send specified data in POST request. Details provided below.</div>
|
||||
<div>-f, --fail Fail silently (don't output HTML error form if returned).</div>
|
||||
<div>-F, --form <name=content> Submit form data.</div>
|
||||
<div>-H, --header <header> Headers to supply with request.</div>
|
||||
<div>-i, --include Include HTTP headers in the output.</div>
|
||||
<div>-I, --head Fetch headers only.</div>
|
||||
<div>-k, --insecure Allow insecure connections to succeed.</div>
|
||||
<div>-L, --location Follow redirects.</div>
|
||||
<div>-o, --output <file> Write output to . Can use --create-dirs in conjunction with this to create any directories specified in the -o path.</div>
|
||||
<div>-O, --remote-name Write output to file named like the remote file (only writes to current directory).</div>
|
||||
<div>-s, --silent Silent (quiet) mode. Use with -S to force it to show errors.</div>
|
||||
<div>-v, --verbose Provide more information (useful for debugging).</div>
|
||||
<div>-w, --write-out <format> Make curl display information on stdout after a completed transfer. See man page for more details on available variables. Convenient way to force curl to append a newline to output: -w "\n" (can add to ~/.curlrc).</div>
|
||||
<div>-X, --request The request method to use.</div>
|
||||
<h2>POST</h2>
|
||||
<div>When sending data via a POST or PUT request, two common formats (specified via the Content-Type header) are:</div>
|
||||
<ul><li><div>application/json</div></li><li><div>application/x-www-form-urlencoded</div></li></ul>
|
||||
<div>Many APIs will accept both formats, so if you're using curl at the command line, it can be a bit easier to use the form urlencoded format instead of json because</div>
|
||||
<ul><li><div>the json format requires a bunch of extra quoting</div></li><li><div>curl will send form urlencoded by default, so for json the Content-Type header must be explicitly set</div></li></ul>
|
||||
<div>This gist provides examples for using both formats, including how to use sample data files in either format with your curl requests.</div>
|
||||
<h2>curl usage</h2>
|
||||
<div>For sending data with POST and PUT requests, these are common curl options:</div>
|
||||
<ul><li><div>request type</div></li><ul><li><div>-X POST</div></li><li><div>-X PUT</div></li></ul><li><div>content type header</div></li><li><div>-H "Content-Type: application/x-www-form-urlencoded"</div></li><li><div>-H "Content-Type: application/json"</div></li><li><div>data</div></li><ul><li><div>form urlencoded: -d "param1=value1&m2=value2" or -d @data.txt</div></li><li><div>json: -d '{"key1":"value1", "key2":"value2"}' or -d @data.json</div></li></ul></ul>
|
||||
<h2>Examples</h2>
|
||||
<h3>POST application/x-www-form-urlencoded</h3>
|
||||
<div>application/x-www-form-urlencoded is the default:</div>
|
||||
<div>curl -d "param1=value1&m2=value2" -X POST http://localhost:3000/data</div>
|
||||
<div>explicit:</div>
|
||||
<div>curl -d "param1=value1&m2=value2" -H "Content-Type: application/x-www-form-urlencoded" -X POST http://localhost:3000/data</div>
|
||||
<div>with a data file</div>
|
||||
<div>curl -d "@data.txt" -X POST http://localhost:3000/data</div>
|
||||
<h3>POST application/json</h3>
|
||||
<div>curl -d '{"key1":"value1", "key2":"value2"}' -H "Content-Type: application/json" -X POST http://localhost:3000/data</div>
|
||||
<div>with a data file</div>
|
||||
<div>curl -d "@data.json" -X POST http://localhost:3000/data</div>
|
||||
<div><br></div>
|
||||
@@ -0,0 +1,15 @@
|
||||
Java parameters references:
|
||||
[Gradle Java Plugin](https://docs.gradle.org/current/userguide/java_plugin.html)
|
||||
|
||||
Running only certain test to debug problems:
|
||||
```
|
||||
gradle test --tests org.gradle.SomeTest.someSpecificFeature
|
||||
gradle test --tests *SomeTest.someSpecificFeature
|
||||
gradle test --tests *SomeSpecificTest
|
||||
gradle test --tests all.in.specific.package*
|
||||
gradle test --tests *IntegTest
|
||||
gradle test --tests *IntegTest*ui*
|
||||
gradle test --tests *IntegTest.singleMethod
|
||||
gradle someTestTask --tests *UiTest someOtherTestTask --tests *WebTest*ui
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user