jmarya/knowledge
jmarya/knowledge
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

add uuid

Browse source
This commit is contained in:
JMARyA 2024-03-08 22:22:49 +01:00
parent 5584be0f1b
commit ba9c43c0bf
Signed by: jmarya
GPG key ID: 901B2ADDF27C2263
5 changed files with 158 additions and 75 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
technology/applications/cli/just.md
View file

@ -530,10 +530,10 @@ These functions can fail, for example if a path does not have an extension, whic
#### Error Reporting
- `error(message)` - Abort execution and report error `message` to user.
#### UUID and Hash Generation
#### [UUID](../../linux/UUID.md) and Hash Generation
- `sha256(string)` - Return the [SHA](../../cryptography/SHA.md)-256 hash of `string` as a hexadecimal string.
- `sha256_file(path)` - Return the [SHA](../../cryptography/SHA.md)-256 hash of the file at `path` as a hexadecimal string.
- `uuid()` - Return a randomly generated UUID.
- `uuid()` - Return a randomly generated [UUID](../../linux/UUID.md).
### Recipe Attributes
Recipes may be annotated with attributes that change their behavior.

142
technology/applications/cli/system/lsblk.md
View file

@ -19,74 +19,74 @@ Usage: `lsblk [options] [device...]`
| `-p, --paths` | Print full device paths |
## Output Columns
| Output | Description |
| ------------ | ------------------------------------------------- |
| ALIGNMENT | alignment offset |
| ID-LINK | the shortest udev /dev/disk/by-id link name |
| ID | udev ID (based on ID-LINK) |
| DISC-ALN | discard alignment offset |
| DAX | dax-capable device |
| DISC-GRAN | discard granularity |
| DISK-SEQ | disk sequence number |
| DISC-MAX | discard max bytes |
| DISC-ZERO | discard zeroes data |
| FSAVAIL | filesystem size available |
| FSROOTS | mounted filesystem roots |
| FSSIZE | filesystem size |
| FSTYPE | filesystem type |
| FSUSED | filesystem size used |
| FSUSE% | filesystem use percentage |
| FSVER | filesystem version |
| GROUP | group name |
| HCTL | Host:Channel:Target:Lun for SCSI |
| HOTPLUG | removable or hotplug device (usb, pcmcia, ...) |
| KNAME | internal kernel device name |
| LABEL | filesystem LABEL |
| LOG-SEC | logical sector size |
| MAJ:MIN | major:minor device number |
| MIN-IO | minimum I/O size |
| MODE | device node permissions |
| MODEL | device identifier |
| MQ | device queues |
| NAME | device name |
| OPT-IO | optimal I/O size |
| OWNER | user name |
| PARTFLAGS | partition flags |
| PARTLABEL | partition LABEL |
| PARTN | partition number as read from the partition table |
| PARTTYPE | partition type code or UUID |
| PARTTYPENAME | partition type name |
| PARTUUID | partition UUID |
| PATH | path to the device node |
| PHY-SEC | physical sector size |
| PKNAME | internal parent kernel device name |
| PTTYPE | partition table type |
| PTUUID | partition table identifier (usually UUID) |
| RA | read-ahead of the device |
| RAND | adds randomness |
| REV | device revision |
| RM | removable device |
| RO | read-only device |
| ROTA | rotational device |
| RQ-SIZE | request queue size |
| SCHED | I/O scheduler name |
| SERIAL | disk serial number |
| SIZE | size of the device |
| START | partition start offset |
| STATE | state of the device |
| SUBSYSTEMS | de-duplicated chain of subsystems |
| MOUNTPOINT | where the device is mounted |
| MOUNTPOINTS | all locations where device is mounted |
| TRAN | device transport type |
| TYPE | device type |
| UUID | filesystem UUID |
| VENDOR | device vendor |
| WSAME | write same max bytes |
| WWN | unique storage identifier |
| ZONED | zone model |
| ZONE-SZ | zone size |
| ZONE-WGRAN | zone write granularity |
| ZONE-APP | zone append max bytes |
| ZONE-NR | number of zones |
| ZONE-OMAX | maximum number of open zones |
| ZONE-AMAX | maximum number of active zones |
| Output | Description |
| ------------ | ------------------------------------------------------------------- |
| ALIGNMENT | alignment offset |
| ID-LINK | the shortest udev /dev/disk/by-id link name |
| ID | udev ID (based on ID-LINK) |
| DISC-ALN | discard alignment offset |
| DAX | dax-capable device |
| DISC-GRAN | discard granularity |
| DISK-SEQ | disk sequence number |
| DISC-MAX | discard max bytes |
| DISC-ZERO | discard zeroes data |
| FSAVAIL | filesystem size available |
| FSROOTS | mounted filesystem roots |
| FSSIZE | filesystem size |
| FSTYPE | filesystem type |
| FSUSED | filesystem size used |
| FSUSE% | filesystem use percentage |
| FSVER | filesystem version |
| GROUP | group name |
| HCTL | Host:Channel:Target:Lun for SCSI |
| HOTPLUG | removable or hotplug device (usb, pcmcia, ...) |
| KNAME | internal kernel device name |
| LABEL | filesystem LABEL |
| LOG-SEC | logical sector size |
| MAJ:MIN | major:minor device number |
| MIN-IO | minimum I/O size |
| MODE | device node permissions |
| MODEL | device identifier |
| MQ | device queues |
| NAME | device name |
| OPT-IO | optimal I/O size |
| OWNER | user name |
| PARTFLAGS | partition flags |
| PARTLABEL | partition LABEL |
| PARTN | partition number as read from the partition table |
| PARTTYPE | partition type code or [UUID](../../../linux/UUID.md) |
| PARTTYPENAME | partition type name |
| PARTUUID | partition [UUID](../../../linux/UUID.md) |
| PATH | path to the device node |
| PHY-SEC | physical sector size |
| PKNAME | internal parent kernel device name |
| PTTYPE | partition table type |
| PTUUID | partition table identifier (usually [UUID](../../../linux/UUID.md)) |
| RA | read-ahead of the device |
| RAND | adds randomness |
| REV | device revision |
| RM | removable device |
| RO | read-only device |
| ROTA | rotational device |
| RQ-SIZE | request queue size |
| SCHED | I/O scheduler name |
| SERIAL | disk serial number |
| SIZE | size of the device |
| START | partition start offset |
| STATE | state of the device |
| SUBSYSTEMS | de-duplicated chain of subsystems |
| MOUNTPOINT | where the device is mounted |
| MOUNTPOINTS | all locations where device is mounted |
| TRAN | device transport type |
| TYPE | device type |
| UUID | filesystem [UUID](../../../linux/UUID.md) |
| VENDOR | device vendor |
| WSAME | write same max bytes |
| WWN | unique storage identifier |
| ZONED | zone model |
| ZONE-SZ | zone size |
| ZONE-WGRAN | zone write granularity |
| ZONE-APP | zone append max bytes |
| ZONE-NR | number of zones |
| ZONE-OMAX | maximum number of open zones |
| ZONE-AMAX | maximum number of active zones |

2
technology/files/iCalendar.md
View file

@ -39,7 +39,7 @@ END:VEVENT
END:VCALENDAR
```
The UID field distributes updates when a scheduled event changes. When the event is first generated a globally unique identifier is created. If a later event is distributed with the same UID, it replaces the original one. An example UID might be `Y2007S2C131M5@example.edu`, for the 5th meeting of class 131 in semester 2 at a hypothetical college. Email-style UIDs are now considered bad practice, with a UUID recommended instead.
The UID field distributes updates when a scheduled event changes. When the event is first generated a globally unique identifier is created. If a later event is distributed with the same UID, it replaces the original one. An example UID might be `Y2007S2C131M5@example.edu`, for the 5th meeting of class 131 in semester 2 at a hypothetical college. Email-style UIDs are now considered bad practice, with a [UUID](../linux/UUID.md) recommended instead.
The most common representation of date and time is a tz timestamp such as `20010911T124640Z` with the format `<year (4 digits)><month (2)><day (2)>T<hour (2)><minute (2)><second (2)>Z` for a total fixed length of 16 characters. Z indicates the use of UTC (referring to its Zulu time zone). When used in `DTSTART` and `DTEND` properties, start times are inclusive while end times are not. This allows an event's end time to be the same as a consecutive event's start without those events overlapping and potentially creating (false) scheduling conflicts.

83
technology/linux/UUID.md Normal file
View file

@ -0,0 +1,83 @@
---
obj: concept
wiki: https://en.wikipedia.org/wiki/Universally_unique_identifier
rfc: https://datatracker.ietf.org/doc/html/rfc4122
aliases: ["Universally Unique Identifier", "GUID"]
---
# UUID (Universally Unique Identifier)
A Universally Unique Identifier (UUID) is a 128-bit label used for information in computer systems. The term Globally Unique Identifier (GUID) is also used, mostly in [Microsoft](../internet/websites/clearnet/Microsoft.md) systems.
When generated according to the standard methods, UUIDs are, for practical purposes, unique. Their uniqueness does not depend on a central registration authority or coordination between the parties generating them, unlike most other numbering schemes. While the probability that a UUID will be duplicated is not zero, it is generally considered close enough to zero to be negligible.
Thus, anyone can create a UUID and use it to identify something with near certainty that the identifier does not duplicate one that has already been, or will be, created to identify something else. Information labeled with UUIDs by independent parties can therefore be later combined into a single database or transmitted on the same channel, with a negligible probability of duplication.
Adoption of UUIDs is widespread, with many computing platforms providing support for generating them and for parsing their textual representation.
## Text Representation
Because a UUID is a 128 bit label, it can be represented in different formats.
In most cases, UUIDs are represented as hexadecimal values. The most used format is the 8-4-4-4-12 format, `xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx`, where every x represents 4 bits. Other well-known formats are the 8-4-4-4-12 format with braces, `{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}`, like in [Microsoft](../internet/websites/clearnet/Microsoft.md)'s systems, e.g. [Windows](../windows/Windows.md), or `xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx`, where all hyphens are removed. In some cases, it is also possible to have `xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx` with the "0x" prefix or the "h" suffix to indicate hexadecimal values. The format with hyphens was introduced with the newer variant system.
A UUID can be represented as a 128 bit integer. For example, the UUID `550e8400-e29b-41d4-a716-446655440000` can also be represented as `113059749145936325402354257176981405696`. Note that it is possible to have both signed and unsigned values if the first bit of the UUID is set to 1.
A UUID can be represented as a 128 bit binary number. For example, the UUID `550e8400-e29b-41d4-a716-446655440000` can also be represented as `01010101000011101000010000000000111000101001101101000001110101001010011100010110010001000110011001010101010001000000000000000000`.
RFC 4122 registered the "uuid" namespace. This makes it possible to make URNs out of UUIDs, like `urn:uuid:550e8400-e29b-41d4-a716-446655440000`. The normal 8-4-4-4-12 format is used for this. It is also possible to make a OID URN out of UUIDs, like `urn:oid:2.25.113059749145936325402354257176981405696`. In that case, the unsigned decimal format is used. The "uuid" URN is recommended over the "oid" URN.
## Versions
The OSF DCE variant defines five "versions" in the standard, and each version may be more appropriate than the others in specific use cases. The version is indicated by the value of the higher nibble (higher 4 bits, or higher hexadecimal digit) of the 7th byte of the UUID. In hex, this is the character after the second dash. For example, the UUID `9c5b94b1-35ad-49bb-b118-8e8fc24abf80` is version 4, because of the digit after the second dash is 4 in `...49bb-....`
### Version 1 (date-time and MAC address)
Version 1 concatenates the 48-bit MAC address of the "node" (that is, the computer generating the UUID), with a 60-bit timestamp, being the number of 100-nanosecond intervals since midnight 15 October 1582 Coordinated Universal Time (UTC), the date on which the Gregorian calendar was first adopted outside the Catholic Church and Papal States. RFC 4122 states that the time value rolls over around 3400 AD, depending on the algorithm used, which implies that the 60-bit timestamp is a signed quantity. However some software, such as the `libuuid` library, treats the timestamp as unsigned, putting the rollover time in 5623 AD. The rollover time as defined by ITU-T Rec. X.667 is 3603 AD. 
A 13-bit or 14-bit "uniquifying" clock sequence extends the timestamp in order to handle cases where the processor clock does not advance fast enough, or where there are multiple processors and UUID generators per node. When UUIDs are generated faster than the system clock could advance, the lower bits of the timestamp fields can be generated by incrementing it every time a UUID is being generated, to simulate a high-resolution timestamp. With each version 1 UUID corresponding to a single point in space (the node) and time (intervals and clock sequence), the chance of two properly generated version-1 UUIDs being unintentionally the same is practically nil. Since the time and clock sequence total 74 bits, 274 (1.8×1022, or 18 sextillion) version-1 UUIDs can be generated per node ID, at a maximal average rate of 163 billion per second per node ID.
In contrast to other UUID versions, version-1 and -2 UUIDs based on MAC addresses from network cards rely for their uniqueness in part on an identifier issued by a central registration authority, namely the Organizationally Unique Identifier (OUI) part of the MAC address, which is issued by the IEEE to manufacturers of networking equipment. The uniqueness of version-1 and version-2 UUIDs based on network-card MAC addresses also depends on network-card manufacturers properly assigning unique MAC addresses to their cards, which like other manufacturing processes is subject to error. Additionally some operating systems permit the end user to customise the MAC address, notably OpenWRT.
Usage of the node's network card MAC address for the node ID means that a version-1 UUID can be tracked back to the computer that created it. Documents can sometimes be traced to the computers where they were created or edited through UUIDs embedded into them by word processing software. This privacy hole was used when locating the creator of the Melissa virus.
RFC 4122 does allow the MAC address in a version-1 (or 2) UUID to be replaced by a random 48-bit node ID, either because the node does not have a MAC address, or because it is not desirable to expose it. In that case, the RFC requires that the least significant bit of the first octet of the node ID should be set to 1. This corresponds to the multicast bit in MAC addresses, and setting it serves to differentiate UUIDs where the node ID is randomly generated from UUIDs based on MAC addresses from network cards, which typically have unicast MAC addresses.
### Version 2 (date-time and MAC address, DCE security version)
RFC 4122 reserves version 2 for "DCE security" UUIDs; but it does not provide any details. For this reason, many UUID implementations omit version 2. However, the specification of version-2 UUIDs is provided by the DCE 1.1 Authentication and Security Services specification.
Version-2 UUIDs are similar to version 1, except that the least significant 8 bits of the clock sequence are replaced by a "local domain" number, and the least significant 32 bits of the timestamp are replaced by an integer identifier meaningful within the specified local domain. On POSIX systems, local-domain numbers 0 and 1 are for user ids (UIDs) and group ids (GIDs) respectively, and other local-domain numbers are site-defined. On non-POSIX systems, all local domain numbers are site-defined.
The ability to include a 40-bit domain/identifier in the UUID comes with a tradeoff. On the one hand, 40 bits allow about 1 trillion domain/identifier values per node ID. On the other hand, with the clock value truncated to the 28 most significant bits, compared to 60 bits in version 1, the clock in a version 2 UUID will "tick" only once every 429.49 seconds, a little more than 7 minutes, as opposed to every 100 nanoseconds for version 1. And with a clock sequence of only 6 bits, compared to 14 bits in version 1, only 64 unique UUIDs per node/domain/identifier can be generated per 7-minute clock tick, compared to 16,384 clock sequence values for version 1. Thus, Version 2 may not be suitable for cases where UUIDs are required, per node/domain/identifier, at a rate exceeding about one every seven minutes.
### Versions 3 and 5 (namespace name-based)
Version-3 and version-5 UUIDs are generated by hashing a namespace identifier and name. Version 3 uses MD5 as the hashing algorithm, and version 5 uses [SHA-1](../cryptography/SHA.md).
The namespace identifier is itself a UUID. The specification provides UUIDs to represent the namespaces for URLs, fully qualified domain names, object identifiers, and X.500 distinguished names; but any desired UUID may be used as a namespace designator.
To determine the version-3 UUID corresponding to a given namespace and name, the UUID of the namespace is transformed to a string of bytes, concatenated with the input name, then hashed with MD5, yielding 128 bits. Then 6 or 7 bits are replaced by fixed values, the 4-bit version (e.g. 00112 for version 3), and the 2- or 3-bit UUID "variant" (e.g. 102 indicating a RFC 4122 UUIDs, or 1102 indicating a legacy [Microsoft](../internet/websites/clearnet/Microsoft.md) GUID). Since 6 or 7 bits are thus predetermined, only 121 or 122 bits contribute to the uniqueness of the UUID.
Version-5 UUIDs are similar, but [SHA-1](../cryptography/SHA.md) is used instead of MD5. Since [SHA-1](../cryptography/SHA.md) generates 160-bit digests, the digest is truncated to 128 bits before the version and variant bits are replaced.
Version-3 and version-5 UUIDs have the property that the same namespace and name will map to the same UUID. However, neither the namespace nor name can be determined from the UUID, even if one of them is specified, except by brute-force search. RFC 4122 recommends version 5 ([SHA-1](../cryptography/SHA.md)) over version 3 (MD5), and warns against use of UUIDs of either version as security credentials.
### Version 4 (random)
A version 4 UUID is randomly generated. As in other UUIDs, 4 bits are used to indicate version 4, and 2 or 3 bits to indicate the variant. Thus, for variant 1 (that is, most UUIDs) a random version-4 UUID will have 6 predetermined variant and version bits, leaving 122 bits for the randomly generated part, for a total of $2^{122}$, or $5.3×10^{36}$ (5.3 undecillion) possible version-4 variant-1 UUIDs. There are half as many possible version-4 variant-2 UUIDs (legacy GUIDs) because there is one less random bit available, 3 bits being consumed for the variant.
## Special UUIDs
The "nil" UUID, a special case, is the UUID `00000000-0000-0000-0000-000000000000`; that is, all bits set to zero.
The "max" UUID, a special case, is the UUID `FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF`; that is, all bits set to one.
## Collisions
Collision occurs when the same UUID is generated more than once and assigned to different referents. In the case of standard version-1 and version-2 UUIDs using unique MAC addresses from network cards, collisions are unlikely to occur, with an increased possibility only when an implementation varies from the standards, either inadvertently or intentionally.
In contrast to version-1 and version-2 UUIDs generated using MAC addresses, with version-1 and -2 UUIDs which use randomly generated node ids, hash-based version-3 and version-5 UUIDs, and random version-4 UUIDs, collisions can occur even without implementation problems, albeit with a probability so small that it can normally be ignored. This probability can be computed precisely based on analysis of the birthday problem.
For example, the number of random version-4 UUIDs which need to be generated in order to have a 50% probability of at least one collision is 2.71 quintillion, computed as follows:
${\displaystyle n\approx {\frac {1}{2}}+{\sqrt {{\frac {1}{4}}+2\times \ln(2)\times 2^{122}}}\approx 2.71\times 10^{18}.}$
This number is equivalent to generating 1 billion UUIDs per second for about 86 years. A file containing this many UUIDs, at 16 bytes per UUID, would be about 45 exabytes.
The smallest number of version-4 UUIDs which must be generated for the probability of finding a collision to be $p$ is approximated by the formula
$2 × 2 122 × ln ⁡ 1 1 − p . {\displaystyle {\sqrt {2\times 2^{122}\times \ln {\frac {1}{1-p}}}}.}$
Thus, the probability to find a duplicate within 103 trillion version-4 UUIDs is one in a billion.

2
technology/tools/JSON Schema.md
View file

@ -62,7 +62,7 @@ Dates and times are represented in [RFC 3339, section 5.6](https://tools.ietf.or
- `"ipv6"`: IPv6 address, as defined in [RFC 2373, section 2.2](http://tools.ietf.org/html/rfc2373#section-2.2).
###### Resource identifiers
- `"uuid"`: A Universally Unique Identifier as defined by [RFC 4122](https://datatracker.ietf.org/doc/html/rfc4122). Example: `3e4666bf-d5e5-4aa7-b8ce-cefe41c7568a`
- `"uuid"`: A [Universally Unique Identifier](../linux/UUID.md) as defined by [RFC 4122](https://datatracker.ietf.org/doc/html/rfc4122). Example: `3e4666bf-d5e5-4aa7-b8ce-cefe41c7568a`
- `"uri"`: A universal resource identifier (URI), according to [RFC3986](http://tools.ietf.org/html/rfc3986).
- `"uri-reference"`: A URI Reference (either a URI or a relative-reference), according to [RFC3986, section 4.1](http://tools.ietf.org/html/rfc3986#section-4.1).
- `"iri"`: The internationalized equivalent of a "uri", according to [RFC3987](https://tools.ietf.org/html/rfc3987).