major updates

This commit is contained in:
2023-11-11 12:32:35 -07:00
parent 6566454d27
commit 6d22eee90c
70 changed files with 30 additions and 2129 deletions

Binary file not shown.

View File

@@ -1,127 +0,0 @@
**Fusion of "Team" and "Cooking" Themes**:
- TeamTaste.com
- CookingCohesion.com
- CulinaryCollab.com
- TeamPlatter.com
- CookingComrades.com
**Chef-Centric Names**:
- ChefTeamBuilder.com
- CulinaryCraftTeams.com
- ChefPartyPros.com
- TheTeamChef.com
- CorporateChefCrew.com
**"Experience" Oriented**:
- EpicureanEscapades.com
- CookTogetherExperience.com
- CulinaryQuests.com
- GourmetGatherings.com
- FlavorFestivities.com
**Workshop and Party Fusion**:
- CulinaryCraftshops.com
- CookFestWorkshops.com
- KitchenPartyWorks.com
- ChefJamSessions.com
- CulinaryCanvasWorkshops.com
**"Playful & Fun" oriented**:
- SizzleSquads.com
- GourmetGiggles.com
- PanPartyPals.com
- FoodieFunFests.com
- ChefChucklesEvents.com
**Corporate-Focused**:
- CorporateCookouts.com
- BoardroomBites.com
- ExecEatsEvents.com
- TeamTasteTest.com
- BizBiteWorkshops.com
**Playful Chef Pseudonyms**:
- ChefFiesta.com
- ChefMingle.com
- ChefBuddyBakes.com
- ChefWhiskWiz.com
- ChefGiggleGrub.com
**Abbreviation or Slang Play**:
- ChefG2G (Good to Go).com
- ChefNChill.com
- TheChefHub.com
- Chef2ChefSessions.com
- ChefLOL (Lots of Love/Laugh Out Loud) .com
**Fusion of Chef Identity & Experience**:
- CajunCrewCooks.com
- ChefGigFests.com
- ChefGGGatherings.com
- ChefFusionFests.com
- ChefTasteTeams.com
**Cuisine-Specific (Taking "Cajun" as an example)**:
- CajunCamaraderie.com
- CorporateCajunCooks.com
- CajunKitchenKrew.com
- TeamBayouBites.com
- CajunCookCrews.com
**Modern & Trendy**:
- ChefLitLunches.com
- ChefUpEvents.com
- ChefSquadGoals.com
- TheTrendyTasteTeam.com
- ChefVibeVents.com
**Using "Gi" (assumed abbreviation for their name or nickname)**:
- GiTheCreoleChef.com
- ChefGiCreole.com
- SpicyGiCooks.com
- CreoleKingGi.com
- GiGourmetCreole.com
**Play on "Spicy" and "Creole" Elements**:
- SpicyCreoleGatherings.com
- CreoleCuisineCrews.com
- SpicyTeamTreats.com
- HotCreoleHangouts.com
- FieryCreoleFeasts.com
**Modern & Playful**:
- CreoleChefChill.com
- GiNChillCreole.com
- SpicySquadSessions.com
- GiCooksHot.com
- CreoleCrunchWithGi.com
**Corporate & Team Building Themes**:
- SpicyTeamSync.com
- CreoleCollaborate.com
- GiCulinaryTeam.com
- SpicySquadWorkshops.com
- CreoleCorporateCookouts.com
**Using "Gi" and Emphasizing Experience**:
- GiCreoleExperience.com
- SpicySessionsWithGi.com
- GiCreoleCraft.com
- CreoleCookingWithGi.com
- TheCreoleCornerByGi.com

BIN
random/.DS_Store vendored

Binary file not shown.

View File

@@ -1,28 +0,0 @@
# Dictionary
They are also known as mapping type, they map keys to the values.
## What data types you can use for keys in Python dictionary?
Any data type which is immutable can be used as a key. To understand this behavior we would
need to understand how dictionary works behind the scene, which is too
advanced for this course.
For now just remember that immutable data types such as **string, int, float, boolean, tuples,** etc, can be used
as keys.
```python
pizza = {
10: "small",
8.99: "price",
("cheese", "olives"): "toppings",
True: "available",
}
print(pizza[10]) # prints => "small"
print(pizza[8.99]) # prints => "price"
print(pizza[("cheese", "olives")]) # prints => "toppings"
print(pizza[True]) # prints => "available"
```
`pizza` is also a perfectly valid dictionary, but does not have practical usability.

View File

@@ -1,16 +0,0 @@
mgt - 192.168.1.0/24
lan - 192.168.2.0/24
wlan - 192.168.3.0/24
iot - 192.168.4.0/24
kids - 192.168.5.0/24
guest - 192.168.6.0/24
lab - 192.168.7.0/24
dmz - 192.168.8.0/24
LIC-MX64-SEC-3YR
LIC-MX84-SEC-3YR
LIC-MX100-SEC-3YR
https://www.cisco.com/c/en/us/products/collateral/software/one-wan-subscription/guide-c07-740642.html

View File

@@ -1,90 +0,0 @@
# socks examples
## Example for SOCKS 'associate' command
The associate command tells the SOCKS proxy server to establish a UDP relay. The server binds to a new UDP port and communicates the newly opened port back to the origin client. From here, any SOCKS UDP frame packets sent to this special UDP port on the Proxy server will be forwarded to the desired destination, and any responses will be forwarded back to the origin client (you).
This can be used for things such as DNS queries, and other UDP communicates.
**Connection Steps**
1. Client -(associate)-> Proxy (Tells the proxy to create a UDP relay and bind on a new port)
2. Client <-(port)- Proxy (Tells the origin client which port it opened and is accepting UDP frame packets on)
At this point the proxy is accepting UDP frames on the specified port.
3. Client --(udp frame) -> Proxy -> Destination (The origin client sends a UDP frame to the proxy on the UDP port, and the proxy then forwards it to the destination specified in the UDP frame.)
4. Client <--(udp frame) <-- Proxy <-- Destination (The destination client responds to the udp packet sent in #3)
## Usage
The 'associate' command can only be used by creating a new SocksClient instance and listening for the 'established' event.
**Note:** UDP packets relayed through the proxy servers are encompassed in a special Socks UDP frame format. SocksClient.createUDPFrame() and SocksClient.parseUDPFrame() create and parse these special UDP packets.
```typescript
const dgram = require('dgram');
const SocksClient = require('socks').SocksClient;
// Create a local UDP socket for sending/receiving packets to/from the proxy.
const udpSocket = dgram.createSocket('udp4');
udpSocket.bind();
// Listen for incoming UDP packets from the proxy server.
udpSocket.on('message', (message, rinfo) => {
console.log(SocksClient.parseUDPFrame(message));
/*
{ frameNumber: 0,
remoteHost: { host: '8.8.8.8', port: 53 }, // The remote host that replied with a UDP packet
data: <Buffer 74 65 73 74 0a> // The data
}
*/
});
const options = {
proxy: {
host: '104.131.124.203',
port: 1081,
type: 5
},
// This should be the ip and port of the expected client that will be sending UDP frames to the newly opened UDP port on the server.
// Most SOCKS servers accept 0.0.0.0 as a wildcard address to accept UDP frames from any source.
destination: {
host: '0.0.0.0',
port: 0
},
command: 'associate'
};
const client = new SocksClient(options);
// This event is fired when the SOCKS server has started listening on a new UDP port for UDP relaying.
client.on('established', info => {
console.log(info);
/*
{
socket: <Socket ...>,
remoteHost: { // This is the remote port on the SOCKS proxy server to send UDP frame packets to.
host: '104.131.124.203',
port: 58232
}
}
*/
// Send a udp frame to 8.8.8.8 on port 53 through the proxy.
const packet = SocksClient.createUDPFrame({
remoteHost: { host: '8.8.8.8', port: 53 },
data: Buffer.from('hello') // A DNS lookup in the real world.
});
// Send packet.
udpSocket.send(packet, info.remoteHost.port, info.remoteHost.host);
});
// SOCKS proxy failed to bind.
client.on('error', () => {
// Handle errors
});
```

File diff suppressed because one or more lines are too long

View File

@@ -1,265 +0,0 @@
# socks examples
## Example for SOCKS 'connect' command
The connect command is the most common use-case for a SOCKS proxy. This establishes a direct connection to a destination host through a proxy server. The destination host only has knowledge of the proxy server connecting to it and does not know about the origin client (you).
**Origin Client (you) <-> Proxy Server <-> Destination Server**
In this example, we are connecting to a web server on port 80, and sending a very basic HTTP request to receive a response. It's worth noting that there are many socks-http-agents that can be used with the node http module (and libraries such as request.js) to make this easier. This HTTP request is used as a simple example.
The 'connect' command can be used via the SocksClient.createConnection() factory function as well as by creating a SocksClient instance and using event handlers.
### Using createConnection with async/await
Since SocksClient.createConnection returns a Promise, we can easily use async/await for flow control.
```typescript
import { SocksClient, SocksClientOptions } from 'socks';
const options: SocksClientOptions = {
proxy: {
host: '104.131.124.203',
port: 1081,
type: 5
},
destination: {
host: 'ip-api.com', // host names are supported with SOCKS v4a and SOCKS v5.
port: 80
},
command: 'connect'
};
async function start() {
try {
const info = await SocksClient.createConnection(options);
console.log(info.socket);
// <Socket ...> (this is a raw net.Socket that is established to the destination host through the given proxy servers)
info.socket.write('GET /json HTTP/1.1\nHost: ip-api.com\n\n');
info.socket.on('data', (data) => {
console.log(data.toString()); // ip-api.com sees that the last proxy (104.131.124.203) is connected to it and not the origin client (you).
/*
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/json; charset=utf-8
Date: Sun, 24 Dec 2017 03:47:51 GMT
Content-Length: 300
{
"as":"AS14061 Digital Ocean, Inc.",
"city":"Clifton",
"country":"United States",
"countryCode":"US",
"isp":"Digital Ocean",
"lat":40.8326,
"lon":-74.1307,
"org":"Digital Ocean",
"query":"104.131.124.203",
"region":"NJ",
"regionName":"New Jersey",
"status":"success",
"timezone":"America/New_York",
"zip":"07014"
}
*/
});
} catch (err) {
// Handle errors
}
}
start();
```
### Using createConnection with Promises
```typescript
import { SocksClient, SocksClientOptions } from 'socks';
const options: SocksClientOptions = {
proxy: {
ipaddress: '104.131.124.203',
port: 1081,
type: 5
},
destination: {
host: 'ip-api.com', // host names are supported with SOCKS v4a and SOCKS v5.
port: 80
},
command: 'connect'
};
SocksClient.createConnection(options)
.then(info => {
console.log(info.socket);
// <Socket ...> (this is a raw net.Socket that is established to the destination host through the given proxy servers)
info.socket.write('GET /json HTTP/1.1\nHost: ip-api.com\n\n');
info.socket.on('data', (data) => {
console.log(data.toString()); // ip-api.com sees that the last proxy (104.131.124.203) is connected to it and not the origin client (you).
/*
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/json; charset=utf-8
Date: Sun, 24 Dec 2017 03:47:51 GMT
Content-Length: 300
{
"as":"AS14061 Digital Ocean, Inc.",
"city":"Clifton",
"country":"United States",
"countryCode":"US",
"isp":"Digital Ocean",
"lat":40.8326,
"lon":-74.1307,
"org":"Digital Ocean",
"query":"104.131.124.203",
"region":"NJ",
"regionName":"New Jersey",
"status":"success",
"timezone":"America/New_York",
"zip":"07014"
}
*/
});
})
.catch(err => {
// handle errors
});
```
### Using createConnection with callbacks
SocksClient.createConnection() optionally accepts a callback function as a second parameter.
**Note:** If a callback function is provided, a Promise is still returned from the function, but the promise will always resolve regardless of if there was en error. (tldr: Do not mix callbacks and Promises).
```typescript
import { SocksClient, SocksClientOptions } from 'socks';
const options: SocksClientOptions = {
proxy: {
ipaddress: '104.131.124.203',
port: 1081,
type: 5
},
destination: {
host: 'ip-api.com', // host names are supported with SOCKS v4a and SOCKS v5.
port: 80
},
command: 'connect'
};
SocksClient.createConnection(options, (err, info) => {
if (err) {
// handle errors
} else {
console.log(info.socket);
// <Socket ...> (this is a raw net.Socket that is established to the destination host through the given proxy servers)
info.socket.write('GET /json HTTP/1.1\nHost: ip-api.com\n\n');
info.socket.on('data', (data) => {
console.log(data.toString()); // ip-api.com sees that the last proxy (104.131.124.203) is connected to it and not the origin client (you).
/*
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/json; charset=utf-8
Date: Sun, 24 Dec 2017 03:47:51 GMT
Content-Length: 300
{
"as":"AS14061 Digital Ocean, Inc.",
"city":"Clifton",
"country":"United States",
"countryCode":"US",
"isp":"Digital Ocean",
"lat":40.8326,
"lon":-74.1307,
"org":"Digital Ocean",
"query":"104.131.124.203",
"region":"NJ",
"regionName":"New Jersey",
"status":"success",
"timezone":"America/New_York",
"zip":"07014"
}
*/
});
}
})
```
### Using event handlers
SocksClient also supports instance creation of a SocksClient. This allows for event based flow control.
```typescript
import { SocksClient, SocksClientOptions } from 'socks';
const options: SocksClientOptions = {
proxy: {
ipaddress: '104.131.124.203',
port: 1081,
type: 5
},
destination: {
host: 'ip-api.com', // host names are supported with SOCKS v4a and SOCKS v5.
port: 80
},
command: 'connect'
};
const client = new SocksClient(options);
client.on('established', (info) => {
console.log(info.socket);
// <Socket ...> (this is a raw net.Socket that is established to the destination host through the given proxy servers)
info.socket.write('GET /json HTTP/1.1\nHost: ip-api.com\n\n');
info.socket.on('data', (data) => {
console.log(data.toString()); // ip-api.com sees that the last proxy (104.131.124.203) is connected to it and not the origin client (you).
/*
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/json; charset=utf-8
Date: Sun, 24 Dec 2017 03:47:51 GMT
Content-Length: 300
{
"as":"AS14061 Digital Ocean, Inc.",
"city":"Clifton",
"country":"United States",
"countryCode":"US",
"isp":"Digital Ocean",
"lat":40.8326,
"lon":-74.1307,
"org":"Digital Ocean",
"query":"104.131.124.203",
"region":"NJ",
"regionName":"New Jersey",
"status":"success",
"timezone":"America/New_York",
"zip":"07014"
}
*/
});
});
// Failed to establish proxy connection to destination.
client.on('error', () => {
// Handle errors
});
// Start connection
client.connect();
```

View File

@@ -1,258 +0,0 @@
# socks examples
## Example for SOCKS 'connect' command
The connect command is the most common use-case for a SOCKS proxy. This establishes a direct connection to a destination host through a proxy server. The destination host only has knowledge of the proxy server connecting to it and does not know about the origin client (you).
**Origin Client (you) <-> Proxy Server <-> Destination Server**
In this example, we are connecting to a web server on port 80, and sending a very basic HTTP request to receive a response. It's worth noting that there are many socks-http-agents that can be used with the node http module (and libraries such as request.js) to make this easier. This HTTP request is used as a simple example.
The 'connect' command can be used via the SocksClient.createConnection() factory function as well as by creating a SocksClient instance and using event handlers.
### Using createConnection with async/await
Since SocksClient.createConnection returns a Promise, we can easily use async/await for flow control.
```typescript
const SocksClient = require('socks').SocksClient;
const options = {
proxy: {
host: '104.131.124.203',
port: 1081,
type: 5
},
destination: {
host: 'ip-api.com', // host names are supported with SOCKS v4a and SOCKS v5.
port: 80
},
command: 'connect'
};
async function start() {
try {
const info = await SocksClient.createConnection(options);
console.log(info.socket);
// <Socket ...> (this is a raw net.Socket that is established to the destination host through the given proxy servers)
info.socket.write('GET /json HTTP/1.1\nHost: ip-api.com\n\n');
info.socket.on('data', (data) => {
console.log(data.toString()); // ip-api.com sees that the last proxy (104.131.124.203) is connected to it and not the origin client (you).
/*
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/json; charset=utf-8
Date: Sun, 24 Dec 2017 03:47:51 GMT
Content-Length: 300
{
"as":"AS14061 Digital Ocean, Inc.",
"city":"Clifton",
"country":"United States",
"countryCode":"US",
"isp":"Digital Ocean",
"lat":40.8326,
"lon":-74.1307,
"org":"Digital Ocean",
"query":"104.131.124.203",
"region":"NJ",
"regionName":"New Jersey",
"status":"success",
"timezone":"America/New_York",
"zip":"07014"
}
*/
} catch (err) {
// Handle errors
}
}
start();
```
### Using createConnection with Promises
```typescript
const SocksClient = require('socks').SocksClient;
const options = {
proxy: {
ipaddress: '104.131.124.203',
port: 1081,
type: 5
},
destination: {
host: 'ip-api.com', // host names are supported with SOCKS v4a and SOCKS v5.
port: 80
},
command: 'connect'
};
SocksClient.createConnection(options)
.then(info => {
console.log(info.socket);
// <Socket ...> (this is a raw net.Socket that is established to the destination host through the given proxy servers)
info.socket.write('GET /json HTTP/1.1\nHost: ip-api.com\n\n');
info.socket.on('data', (data) => {
console.log(data.toString()); // ip-api.com sees that the last proxy (104.131.124.203) is connected to it and not the origin client (you).
/*
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/json; charset=utf-8
Date: Sun, 24 Dec 2017 03:47:51 GMT
Content-Length: 300
{
"as":"AS14061 Digital Ocean, Inc.",
"city":"Clifton",
"country":"United States",
"countryCode":"US",
"isp":"Digital Ocean",
"lat":40.8326,
"lon":-74.1307,
"org":"Digital Ocean",
"query":"104.131.124.203",
"region":"NJ",
"regionName":"New Jersey",
"status":"success",
"timezone":"America/New_York",
"zip":"07014"
}
*/
})
.catch(err => {
// handle errors
});
```
### Using createConnection with callbacks
SocksClient.createConnection() optionally accepts a callback function as a second parameter.
**Note:** If a callback function is provided, a Promise is still returned from the function, but the promise will always resolve regardless of if there was en error. (tldr: Do not mix callbacks and Promises).
```typescript
const SocksClient = require('socks').SocksClient;
const options = {
proxy: {
ipaddress: '104.131.124.203',
port: 1081,
type: 5
},
destination: {
host: 'ip-api.com', // host names are supported with SOCKS v4a and SOCKS v5.
port: 80
},
command: 'connect'
};
SocksClient.createConnection(options, (err, info) => {
if (err) {
// handle errors
} else {
console.log(info.socket);
// <Socket ...> (this is a raw net.Socket that is established to the destination host through the given proxy servers)
info.socket.write('GET /json HTTP/1.1\nHost: ip-api.com\n\n');
info.socket.on('data', (data) => {
console.log(data.toString()); // ip-api.com sees that the last proxy (104.131.124.203) is connected to it and not the origin client (you).
/*
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/json; charset=utf-8
Date: Sun, 24 Dec 2017 03:47:51 GMT
Content-Length: 300
{
"as":"AS14061 Digital Ocean, Inc.",
"city":"Clifton",
"country":"United States",
"countryCode":"US",
"isp":"Digital Ocean",
"lat":40.8326,
"lon":-74.1307,
"org":"Digital Ocean",
"query":"104.131.124.203",
"region":"NJ",
"regionName":"New Jersey",
"status":"success",
"timezone":"America/New_York",
"zip":"07014"
}
*/
}
})
```
### Using event handlers
SocksClient also supports instance creation of a SocksClient. This allows for event based flow control.
```typescript
const SocksClient = require('socks').SocksClient;
const options = {
proxy: {
ipaddress: '104.131.124.203',
port: 1081,
type: 5
},
destination: {
host: 'ip-api.com', // host names are supported with SOCKS v4a and SOCKS v5.
port: 80
},
command: 'connect'
};
const client = new SocksClient(options);
client.on('established', (info) => {
console.log(info.socket);
// <Socket ...> (this is a raw net.Socket that is established to the destination host through the given proxy servers)
info.socket.write('GET /json HTTP/1.1\nHost: ip-api.com\n\n');
info.socket.on('data', (data) => {
console.log(data.toString()); // ip-api.com sees that the last proxy (104.131.124.203) is connected to it and not the origin client (you).
/*
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/json; charset=utf-8
Date: Sun, 24 Dec 2017 03:47:51 GMT
Content-Length: 300
{
"as":"AS14061 Digital Ocean, Inc.",
"city":"Clifton",
"country":"United States",
"countryCode":"US",
"isp":"Digital Ocean",
"lat":40.8326,
"lon":-74.1307,
"org":"Digital Ocean",
"query":"104.131.124.203",
"region":"NJ",
"regionName":"New Jersey",
"status":"success",
"timezone":"America/New_York",
"zip":"07014"
}
*/
});
// Failed to establish proxy connection to destination.
client.on('error', () => {
// Handle errors
});
```

View File

@@ -1,122 +0,0 @@
# The Frame Stack
Each call to a Python function has an activation record,
commonly known as a "frame".
Python semantics allows frames to outlive the activation,
so they have (before 3.11) been allocated on the heap.
This is expensive as it requires many allocations and
results in poor locality of reference.
In 3.11, rather than have these frames scattered about memory,
as happens for heap-allocated objects, frames are allocated
contiguously in a per-thread stack.
This improves performance significantly for two reasons:
* It reduces allocation overhead to a pointer comparison and increment.
* Stack allocated data has the best possible locality and will always be in
CPU cache.
Generator and coroutines still need heap allocated activation records, but
can be linked into the per-thread stack so as to not impact performance too much.
## Layout
Each activation record consists of four conceptual sections:
* Local variables (including arguments, cells and free variables)
* Evaluation stack
* Specials: The per-frame object references needed by the VM: globals dict,
code object, etc.
* Linkage: Pointer to the previous activation record, stack depth, etc.
### Layout
The specials and linkage sections are a fixed size, so are grouped together.
Each activation record is laid out as:
* Specials and linkage
* Locals
* Stack
This seems to provide the best performance without excessive complexity.
It needs the interpreter to hold two pointers, a frame pointer and a stack pointer.
#### Alternative layout
An alternative layout that was used for part of 3.11 alpha was:
* Locals
* Specials and linkage
* Stack
This has the advantage that no copying is required when making a call,
as the arguments on the stack are (usually) already in the correct
location for the parameters. However, it requires the VM to maintain
an extra pointer for the locals, which can hurt performance.
A variant that only needs the need two pointers is to reverse the numbering
of the locals, so that the last one is numbered `0`, and the first in memory
is numbered `N-1`.
This allows the locals, specials and linkage to accessed from the frame pointer.
We may implement this in the future.
#### Note:
> In a contiguous stack, we would need to save one fewer registers, as the
> top of the caller's activation record would be the same at the base of the
> callee's. However, since some activation records are kept on the heap we
> cannot do this.
### Generators and Coroutines
Generators and coroutines contain a `_PyInterpreterFrame`
The specials sections contains the following pointers:
* Globals dict
* Builtins dict
* Locals dict (not the "fast" locals, but the locals for eval and class creation)
* Code object
* Heap allocated `PyFrameObject` for this activation record, if any.
* The function.
The pointer to the function is not strictly required, but it is cheaper to
store a strong reference to the function and borrowed references to the globals
and builtins, than strong references to both globals and builtins.
### Frame objects
When creating a backtrace or when calling `sys._getframe()` the frame becomes
visible to Python code. When this happens a new `PyFrameObject` is created
and a strong reference to it placed in the `frame_obj` field of the specials
section. The `frame_obj` field is initially `NULL`.
The `PyFrameObject` may outlive a stack-allocated `_PyInterpreterFrame`.
If it does then `_PyInterpreterFrame` is copied into the `PyFrameObject`,
except the evaluation stack which must be empty at this point.
The linkage section is updated to reflect the new location of the frame.
This mechanism provides the appearance of persistent, heap-allocated
frames for each activation, but with low runtime overhead.
### Generators and Coroutines
Generator objects have a `_PyInterpreterFrame` embedded in them.
This means that creating a generator requires only a single allocation,
reducing allocation overhead and improving locality of reference.
The embedded frame is linked into the per-thread frame when iterated or
awaited.
If a frame object associated with a generator outlives the generator, then
the embedded `_PyInterpreterFrame` is copied into the frame object.
All the above applies to coroutines and async generators as well.
### Field names
Many of the fields in `_PyInterpreterFrame` were copied from the 3.10 `PyFrameObject`.
Thus, some of the field names may be a bit misleading.
For example the `f_globals` field has a `f_` prefix implying it belongs to the
`PyFrameObject` struct, although it belongs to the `_PyInterpreterFrame` struct.
We may rationalize this naming scheme for 3.12.

View File

@@ -1,410 +0,0 @@
# Installing Guacamole with Docker
Guacamole can be deployed using Docker, removing the need to build
guacamole-server from source or configure the web application manually. The
Guacamole project provides officially-supported Docker images for both
Guacamole and guacd which are kept up-to-date with each release.
A typical Docker deployment of Guacamole will involve three separate
containers, linked together at creation time:
`guacamole/guacd`
: Provides the guacd daemon, built from the released guacamole-server source
with support for VNC, RDP, SSH, telnet, and Kubernetes.
`guacamole/guacamole`
: Provides the Guacamole web application running within Tomcat 8 with support
for WebSocket. The configuration necessary to connect to guacd, MySQL,
PostgreSQL, LDAP, etc. will be generated automatically when the image starts
based on Docker links or environment variables.
`mysql` or `postgresql`
: Provides the database that Guacamole will use for authentication and storage
of connection configuration data.
This separation is important, as it facilitates upgrades and maintains proper
separation of concerns. With the database separate from Guacamole and guacd,
those containers can be freely destroyed and recreated at will. The only
container which must persist data through upgrades is the database.
(guacd-docker-image)=
## Running the guacd Docker image
The guacd Docker image is built from the released guacamole-server source with
support for VNC, RDP, SSH, telnet, and Kubernetes. Common pitfalls like
installing the required dependencies, installing fonts for SSH, telnet, or
Kubernetes, and ensuring the FreeRDP plugins are installed to the correct
location are all taken care of. It will simply just work.
(guacd-docker-guacamole)=
### Running guacd for use by the Guacamole Docker image
When running the guacd image with the intent of linking to a Guacamole
container, no ports need be exposed on the network. Access to these ports will
be handled automatically by Docker during linking, and the Guacamole image will
properly detect and configure the connection to guacd.
```console
$ docker run --name some-guacd -d guacamole/guacd
```
When run in this manner, guacd will be listening on its default port 4822, but
this port will only be available to Docker containers that have been explicitly
linked to `some-guacd`.
The log level of guacd can be controlled with the `GUACD_LOG_LEVEL` environment
variable. The default value is `info`, and can be set to any of the valid
settings for the guacd log flag (-L).
```console
$ docker run -e GUACD_LOG_LEVEL=debug -d guacamole/guacd
```
(guacd-docker-external)=
### Running guacd for use by services outside Docker
If you are not going to use the Guacamole image, you can still leverage the
guacd image for ease of installation and maintenance. By exposing the guacd
port, 4822, services external to Docker will be able to access guacd.
:::{important}
_Take great care when doing this_ - guacd is a passive proxy and does not
perform any kind of authentication.
If you do not properly isolate guacd from untrusted parts of your network,
malicious users may be able to use guacd as a jumping point to other systems.
:::
```console
$ docker run --name some-guacd -d -p 4822:4822 guacamole/guacd
```
guacd will now be listening on port 4822, and Docker will expose this port on
the same server hosting Docker. Other services, such as an instance of Tomcat
running outside of Docker, will be able to connect to guacd directly.
(guacamole-docker-image)=
## The Guacamole Docker image
The Guacamole Docker image is built on top of a standard Tomcat 8 image and
takes care of all configuration automatically. The configuration information
required for guacd and the various authentication mechanisms are specified with
environment variables or Docker links given when the container is created.
:::{important}
If using [PostgreSQL](guacamole-docker-postgresql) or [MySQL](guacamole-docker-mysql)
for authentication, _you will need to initialize the database manually_.
Guacamole will not automatically create its own tables, but SQL scripts are
provided to do this.
:::
Once the Guacamole image is running, Guacamole will be accessible at
{samp}`http://{HOSTNAME}:8080/guacamole/`, where `HOSTNAME` is the hostname or
address of the machine hosting Docker.
(guacamole-docker-config-via-env)=
### Configuring Guacamole when using Docker
When running Guacamole using Docker, the traditional approach to configuring
Guacamole by editing `guacamole.properties` is less convenient. When using
Docker, you may wish to make use of the `enable-environment-properties`
configuration property, which allows you to specify values for arbitrary
Guacamole configuration properties using environment variables. This is covered
in [](configuring-guacamole).
(guacamole-docker-guacd)=
### Connecting Guacamole to guacd
The Guacamole Docker image needs to be able to connect to guacd to establish
remote desktop connections, just like any other Guacamole deployment. The
connection information needed by Guacamole will be provided either via a Docker
link or through environment variables.
If you will be using Docker to provide guacd, and you wish to use a Docker link
to connect the Guacamole image to guacd, the connection details are implied by
the Docker link:
```console
$ docker run --name some-guacamole \
--link some-guacd:guacd \
...
-d -p 8080:8080 guacamole/guacamole
```
If you are not using Docker to provide guacd, you will need to provide the
network connection information yourself using additional environment variables:
`GUACD_HOSTNAME`
: The hostname of the guacd instance to use to establish remote desktop
connections. _This is required if you are not using Docker to provide guacd._
`GUACD_PORT`
: The port that Guacamole should use when connecting to guacd. This environment
variable is optional. If not provided, the standard guacd port of 4822 will
be used.
The `GUACD_HOSTNAME` and, if necessary, `GUACD_PORT` environment variables can
thus be used in place of a Docker link if using a Docker link is impossible or
undesirable:
```console
$ docker run --name some-guacamole \
-e GUACD_HOSTNAME=172.17.42.1 \
-e GUACD_PORT=4822 \
...
-d -p 8080:8080 guacamole/guacamole
```
_A connection to guacd is not the only thing required for Guacamole to work_;
some authentication mechanism needs to be configured, as well.
[MySQL](guacamole-docker-mysql), [PostgreSQL](guacamole-docker-postgresql), and
[LDAP](guacamole-docker-ldap) are supported for this, and are described in more
detail in the sections below. If the required configuration options for at
least one authentication mechanism are not provided, the Guacamole image will
not be able to start up, and you will see an error.
(guacamole-docker-mysql)=
### MySQL authentication
To use Guacamole with the MySQL authentication backend, you will need either a
Docker container running the `mysql` image, or network access to a working
installation of MySQL. The connection to MySQL can be specified using either
environment variables or a Docker link.
(initializing-guacamole-docker-mysql)=
#### Initializing the MySQL database
If your database is not already initialized with the Guacamole schema, you will
need to do so prior to using Guacamole. A convenience script for generating the
necessary SQL to do this is included in the Guacamole image.
To generate a SQL script which can be used to initialize a fresh MySQL database
as documented in [](jdbc-auth):
```console
$ docker run --rm guacamole/guacamole /opt/guacamole/bin/initdb.sh --mysql > initdb.sql
```
Alternatively, you can use the SQL scripts included with the database
authentication.
Once this script is generated, you must:
1. Create a database for Guacamole within MySQL, such as `guacamole_db`.
2. Create a user for Guacamole within MySQL with access to this database, such
as `guacamole_user`.
3. Run the script on the newly-created database.
The process for doing this via the {command}`mysql` utility included with MySQL
is documented [](jdbc-auth).
(guacamole-docker-mysql-connecting)=
#### Connecting Guacamole to MySQL
If your MySQL database is provided by another Docker container, and you wish to
use a Docker link to connect the Guacamole image to your database, the
connection details are implied by the Docker link itself:
```console
$ docker run --name some-guacamole \
--link some-guacd:guacd \
--link some-mysql:mysql \
...
-d -p 8080:8080 guacamole/guacamole
```
If you are not using Docker to provide your MySQL database, you will need to
provide the network connection information yourself using additional
environment variables:
`MYSQL_HOSTNAME`
: The hostname of the database to use for Guacamole authentication. _This is
required if you are not using Docker to provide your MySQL database._
`MYSQL_PORT`
: The port that Guacamole should use when connecting to MySQL. This environment
variable is optional. If not provided, the standard MySQL port of 3306 will
be used.
The `MYSQL_HOSTNAME` and, if necessary, `MYSQL_PORT` environment variables can
thus be used in place of a Docker link if using a Docker link is impossible or
undesirable:
```console
$ docker run --name some-guacamole \
--link some-guacd:guacd \
-e MYSQL_HOSTNAME=172.17.42.1 \
...
-d -p 8080:8080 guacamole/guacamole
```
Note that a Docker link to guacd (the `--link some-guacd:guacd` option above)
is not required any more than a Docker link is required for MySQL. The
connection information for guacd can be specified using environment variables,
as described in [](guacamole-docker-guacd).
(guacamole-docker-mysql-required-vars)=
#### Required environment variables
Using MySQL for authentication requires additional configuration parameters
specified via environment variables. These variables collectively describe how
Guacamole will connect to MySQL:
`MYSQL_DATABASE`
: The name of the database to use for Guacamole authentication.
`MYSQL_USER`
: The user that Guacamole will use to connect to MySQL.
`MYSQL_PASSWORD`
: The password that Guacamole will provide when connecting to MySQL as
`MYSQL_USER`.
If any required environment variables are omitted, you will receive an error
message in the logs, and the image will stop. You will then need to recreate
the container with the proper variables specified.
(guacamole-docker-mysql-optional-vars)=
(guacamole-docker-postgresql)=
### PostgreSQL authentication
To use Guacamole with the PostgreSQL authentication backend, you will
need either a Docker container running the `postgres` image, or
network access to a working installation of PostgreSQL. The connection
to PostgreSQL can be specified using either environment variables or a
Docker link.
(initializing-guacamole-docker-postgresql)=
#### Initializing the PostgreSQL database
If your database is not already initialized with the Guacamole schema, you will
need to do so prior to using Guacamole. A convenience script for generating the
necessary SQL to do this is included in the Guacamole image.
To generate a SQL script which can be used to initialize a fresh PostgreSQL
database as documented in [](jdbc-auth):
```console
$ docker run --rm guacamole/guacamole /opt/guacamole/bin/initdb.sh --postgresql > initdb.sql
```
Alternatively, you can use the SQL scripts included with the database
authentication.
Once this script is generated, you must:
1. Create a database for Guacamole within PostgreSQL, such as
`guacamole_db`.
2. Run the script on the newly-created database.
3. Create a user for Guacamole within PostgreSQL with access to the tables and
sequences of this database, such as `guacamole_user`.
The process for doing this via the {command}`psql` and {command}`createdb`
utilities included with PostgreSQL is documented in [](jdbc-auth).
(guacamole-docker-postgresql-connecting)=
#### Connecting Guacamole to PostgreSQL
If your PostgreSQL database is provided by another Docker container, and you
wish to use a Docker link to connect the Guacamole image to your database, the
connection details are implied by the Docker link itself:
```console
$ docker run --name some-guacamole \
--link some-guacd:guacd \
--link some-postgres:postgres \
...
-d -p 8080:8080 guacamole/guacamole
```
If you are not using Docker to provide your PostgreSQL database, you will need
to provide the network connection information yourself using additional
environment variables:
`POSTGRESQL_HOSTNAME`
: The hostname of the database to use for Guacamole authentication. _This is
required if you are not using Docker to provide your PostgreSQL database._
`POSTGRESQL_PORT`
: The port that Guacamole should use when connecting to PostgreSQL. This
environment variable is optional. If not provided, the standard PostgreSQL
port of 5432 will be used.
The `POSTGRESQL_HOSTNAME` and, if necessary, `POSTGRESQL_PORT` environment
variables can thus be used in place of a Docker link if using a Docker link is
impossible or undesirable:
```console
$ docker run --name some-guacamole \
--link some-guacd:guacd \
-e POSTGRESQL_HOSTNAME=172.17.42.1 \
...
-d -p 8080:8080 guacamole/guacamole
```
Note that a Docker link to guacd (the `--link some-guacd:guacd` option above)
is not required any more than a Docker link is required for PostgreSQL. The
connection information for guacd can be specified using environment variables,
as described in [](guacamole-docker-guacd).
(guacamole-docker-postgresql-required-vars)=
#### Required environment variables
Using PostgreSQL for authentication requires additional configuration
parameters specified via environment variables. These variables collectively
describe how Guacamole will connect to PostgreSQL:
`POSTGRESQL_DATABASE`
: The name of the database to use for Guacamole authentication.
`POSTGRESQL_USER`
: The user that Guacamole will use to connect to PostgreSQL.
`POSTGRESQL_PASSWORD`
: The password that Guacamole will provide when connecting to PostgreSQL as
`POSTGRESQL_USER`.
If any required environment variables are omitted, you will receive an
error message in the logs, and the image will stop. You will then need
to recreate the container with the proper variables specified.
(guacamole-docker-postgresql-optional-vars)=
### Verifying the Guacamole install
Once the Guacamole image is running, Guacamole should be accessible at
{samp}`http://{HOSTNAME}:8080/guacamole/`, where `HOSTNAME` is the hostname or
address of the machine hosting Docker, and you _should_ see a login screen. If
using MySQL or PostgreSQL, the database initialization scripts will have
created a default administrative user called "`guacadmin`" with the password
"`guacadmin`". _You should log in and change your password immediately._ If
using LDAP, you should be able to log in as any valid user within your LDAP
directory.
If you cannot access Guacamole, or you do not see a login screen, check
Docker's logs using the `docker logs` command to determine if something is
wrong. Configuration parameters may have been given incorrectly, or the
database may be improperly initialized:
```console
$ docker logs some-guacamole
```

View File

@@ -1,410 +0,0 @@
# Installing Guacamole with Docker
Guacamole can be deployed using Docker, removing the need to build
guacamole-server from source or configure the web application manually. The
Guacamole project provides officially-supported Docker images for both
Guacamole and guacd which are kept up-to-date with each release.
A typical Docker deployment of Guacamole will involve three separate
containers, linked together at creation time:
`guacamole/guacd`
: Provides the guacd daemon, built from the released guacamole-server source
with support for VNC, RDP, SSH, telnet, and Kubernetes.
`guacamole/guacamole`
: Provides the Guacamole web application running within Tomcat 8 with support
for WebSocket. The configuration necessary to connect to guacd, MySQL,
PostgreSQL, LDAP, etc. will be generated automatically when the image starts
based on Docker links or environment variables.
`mysql` or `postgresql`
: Provides the database that Guacamole will use for authentication and storage
of connection configuration data.
This separation is important, as it facilitates upgrades and maintains proper
separation of concerns. With the database separate from Guacamole and guacd,
those containers can be freely destroyed and recreated at will. The only
container which must persist data through upgrades is the database.
(guacd-docker-image)=
## Running the guacd Docker image
The guacd Docker image is built from the released guacamole-server source with
support for VNC, RDP, SSH, telnet, and Kubernetes. Common pitfalls like
installing the required dependencies, installing fonts for SSH, telnet, or
Kubernetes, and ensuring the FreeRDP plugins are installed to the correct
location are all taken care of. It will simply just work.
(guacd-docker-guacamole)=
### Running guacd for use by the Guacamole Docker image
When running the guacd image with the intent of linking to a Guacamole
container, no ports need be exposed on the network. Access to these ports will
be handled automatically by Docker during linking, and the Guacamole image will
properly detect and configure the connection to guacd.
```console
$ docker run --name some-guacd -d guacamole/guacd
```
When run in this manner, guacd will be listening on its default port 4822, but
this port will only be available to Docker containers that have been explicitly
linked to `some-guacd`.
The log level of guacd can be controlled with the `GUACD_LOG_LEVEL` environment
variable. The default value is `info`, and can be set to any of the valid
settings for the guacd log flag (-L).
```console
$ docker run -e GUACD_LOG_LEVEL=debug -d guacamole/guacd
```
(guacd-docker-external)=
### Running guacd for use by services outside Docker
If you are not going to use the Guacamole image, you can still leverage the
guacd image for ease of installation and maintenance. By exposing the guacd
port, 4822, services external to Docker will be able to access guacd.
:::{important}
_Take great care when doing this_ - guacd is a passive proxy and does not
perform any kind of authentication.
If you do not properly isolate guacd from untrusted parts of your network,
malicious users may be able to use guacd as a jumping point to other systems.
:::
```console
$ docker run --name some-guacd -d -p 4822:4822 guacamole/guacd
```
guacd will now be listening on port 4822, and Docker will expose this port on
the same server hosting Docker. Other services, such as an instance of Tomcat
running outside of Docker, will be able to connect to guacd directly.
(guacamole-docker-image)=
## The Guacamole Docker image
The Guacamole Docker image is built on top of a standard Tomcat 8 image and
takes care of all configuration automatically. The configuration information
required for guacd and the various authentication mechanisms are specified with
environment variables or Docker links given when the container is created.
:::{important}
If using [PostgreSQL](guacamole-docker-postgresql) or [MySQL](guacamole-docker-mysql)
for authentication, _you will need to initialize the database manually_.
Guacamole will not automatically create its own tables, but SQL scripts are
provided to do this.
:::
Once the Guacamole image is running, Guacamole will be accessible at
{samp}`http://{HOSTNAME}:8080/guacamole/`, where `HOSTNAME` is the hostname or
address of the machine hosting Docker.
(guacamole-docker-config-via-env)=
### Configuring Guacamole when using Docker
When running Guacamole using Docker, the traditional approach to configuring
Guacamole by editing `guacamole.properties` is less convenient. When using
Docker, you may wish to make use of the `enable-environment-properties`
configuration property, which allows you to specify values for arbitrary
Guacamole configuration properties using environment variables. This is covered
in [](configuring-guacamole).
(guacamole-docker-guacd)=
### Connecting Guacamole to guacd
The Guacamole Docker image needs to be able to connect to guacd to establish
remote desktop connections, just like any other Guacamole deployment. The
connection information needed by Guacamole will be provided either via a Docker
link or through environment variables.
If you will be using Docker to provide guacd, and you wish to use a Docker link
to connect the Guacamole image to guacd, the connection details are implied by
the Docker link:
```console
$ docker run --name some-guacamole \
--link some-guacd:guacd \
...
-d -p 8080:8080 guacamole/guacamole
```
If you are not using Docker to provide guacd, you will need to provide the
network connection information yourself using additional environment variables:
`GUACD_HOSTNAME`
: The hostname of the guacd instance to use to establish remote desktop
connections. _This is required if you are not using Docker to provide guacd._
`GUACD_PORT`
: The port that Guacamole should use when connecting to guacd. This environment
variable is optional. If not provided, the standard guacd port of 4822 will
be used.
The `GUACD_HOSTNAME` and, if necessary, `GUACD_PORT` environment variables can
thus be used in place of a Docker link if using a Docker link is impossible or
undesirable:
```console
$ docker run --name some-guacamole \
-e GUACD_HOSTNAME=172.17.42.1 \
-e GUACD_PORT=4822 \
...
-d -p 8080:8080 guacamole/guacamole
```
_A connection to guacd is not the only thing required for Guacamole to work_;
some authentication mechanism needs to be configured, as well.
[MySQL](guacamole-docker-mysql), [PostgreSQL](guacamole-docker-postgresql), and
[LDAP](guacamole-docker-ldap) are supported for this, and are described in more
detail in the sections below. If the required configuration options for at
least one authentication mechanism are not provided, the Guacamole image will
not be able to start up, and you will see an error.
(guacamole-docker-mysql)=
### MySQL authentication
To use Guacamole with the MySQL authentication backend, you will need either a
Docker container running the `mysql` image, or network access to a working
installation of MySQL. The connection to MySQL can be specified using either
environment variables or a Docker link.
(initializing-guacamole-docker-mysql)=
#### Initializing the MySQL database
If your database is not already initialized with the Guacamole schema, you will
need to do so prior to using Guacamole. A convenience script for generating the
necessary SQL to do this is included in the Guacamole image.
To generate a SQL script which can be used to initialize a fresh MySQL database
as documented in [](jdbc-auth):
```console
$ docker run --rm guacamole/guacamole /opt/guacamole/bin/initdb.sh --mysql > initdb.sql
```
Alternatively, you can use the SQL scripts included with the database
authentication.
Once this script is generated, you must:
1. Create a database for Guacamole within MySQL, such as `guacamole_db`.
2. Create a user for Guacamole within MySQL with access to this database, such
as `guacamole_user`.
3. Run the script on the newly-created database.
The process for doing this via the {command}`mysql` utility included with MySQL
is documented [](jdbc-auth).
(guacamole-docker-mysql-connecting)=
#### Connecting Guacamole to MySQL
If your MySQL database is provided by another Docker container, and you wish to
use a Docker link to connect the Guacamole image to your database, the
connection details are implied by the Docker link itself:
```console
$ docker run --name some-guacamole \
--link some-guacd:guacd \
--link some-mysql:mysql \
...
-d -p 8080:8080 guacamole/guacamole
```
If you are not using Docker to provide your MySQL database, you will need to
provide the network connection information yourself using additional
environment variables:
`MYSQL_HOSTNAME`
: The hostname of the database to use for Guacamole authentication. _This is
required if you are not using Docker to provide your MySQL database._
`MYSQL_PORT`
: The port that Guacamole should use when connecting to MySQL. This environment
variable is optional. If not provided, the standard MySQL port of 3306 will
be used.
The `MYSQL_HOSTNAME` and, if necessary, `MYSQL_PORT` environment variables can
thus be used in place of a Docker link if using a Docker link is impossible or
undesirable:
```console
$ docker run --name some-guacamole \
--link some-guacd:guacd \
-e MYSQL_HOSTNAME=172.17.42.1 \
...
-d -p 8080:8080 guacamole/guacamole
```
Note that a Docker link to guacd (the `--link some-guacd:guacd` option above)
is not required any more than a Docker link is required for MySQL. The
connection information for guacd can be specified using environment variables,
as described in [](guacamole-docker-guacd).
(guacamole-docker-mysql-required-vars)=
#### Required environment variables
Using MySQL for authentication requires additional configuration parameters
specified via environment variables. These variables collectively describe how
Guacamole will connect to MySQL:
`MYSQL_DATABASE`
: The name of the database to use for Guacamole authentication.
`MYSQL_USER`
: The user that Guacamole will use to connect to MySQL.
`MYSQL_PASSWORD`
: The password that Guacamole will provide when connecting to MySQL as
`MYSQL_USER`.
If any required environment variables are omitted, you will receive an error
message in the logs, and the image will stop. You will then need to recreate
the container with the proper variables specified.
(guacamole-docker-mysql-optional-vars)=
(guacamole-docker-postgresql)=
### PostgreSQL authentication
To use Guacamole with the PostgreSQL authentication backend, you will
need either a Docker container running the `postgres` image, or
network access to a working installation of PostgreSQL. The connection
to PostgreSQL can be specified using either environment variables or a
Docker link.
(initializing-guacamole-docker-postgresql)=
#### Initializing the PostgreSQL database
If your database is not already initialized with the Guacamole schema, you will
need to do so prior to using Guacamole. A convenience script for generating the
necessary SQL to do this is included in the Guacamole image.
To generate a SQL script which can be used to initialize a fresh PostgreSQL
database as documented in [](jdbc-auth):
```console
$ docker run --rm guacamole/guacamole /opt/guacamole/bin/initdb.sh --postgresql > initdb.sql
```
Alternatively, you can use the SQL scripts included with the database
authentication.
Once this script is generated, you must:
1. Create a database for Guacamole within PostgreSQL, such as
`guacamole_db`.
2. Run the script on the newly-created database.
3. Create a user for Guacamole within PostgreSQL with access to the tables and
sequences of this database, such as `guacamole_user`.
The process for doing this via the {command}`psql` and {command}`createdb`
utilities included with PostgreSQL is documented in [](jdbc-auth).
(guacamole-docker-postgresql-connecting)=
#### Connecting Guacamole to PostgreSQL
If your PostgreSQL database is provided by another Docker container, and you
wish to use a Docker link to connect the Guacamole image to your database, the
connection details are implied by the Docker link itself:
```console
$ docker run --name some-guacamole \
--link some-guacd:guacd \
--link some-postgres:postgres \
...
-d -p 8080:8080 guacamole/guacamole
```
If you are not using Docker to provide your PostgreSQL database, you will need
to provide the network connection information yourself using additional
environment variables:
`POSTGRESQL_HOSTNAME`
: The hostname of the database to use for Guacamole authentication. _This is
required if you are not using Docker to provide your PostgreSQL database._
`POSTGRESQL_PORT`
: The port that Guacamole should use when connecting to PostgreSQL. This
environment variable is optional. If not provided, the standard PostgreSQL
port of 5432 will be used.
The `POSTGRESQL_HOSTNAME` and, if necessary, `POSTGRESQL_PORT` environment
variables can thus be used in place of a Docker link if using a Docker link is
impossible or undesirable:
```console
$ docker run --name some-guacamole \
--link some-guacd:guacd \
-e POSTGRESQL_HOSTNAME=172.17.42.1 \
...
-d -p 8080:8080 guacamole/guacamole
```
Note that a Docker link to guacd (the `--link some-guacd:guacd` option above)
is not required any more than a Docker link is required for PostgreSQL. The
connection information for guacd can be specified using environment variables,
as described in [](guacamole-docker-guacd).
(guacamole-docker-postgresql-required-vars)=
#### Required environment variables
Using PostgreSQL for authentication requires additional configuration
parameters specified via environment variables. These variables collectively
describe how Guacamole will connect to PostgreSQL:
`POSTGRESQL_DATABASE`
: The name of the database to use for Guacamole authentication.
`POSTGRESQL_USER`
: The user that Guacamole will use to connect to PostgreSQL.
`POSTGRESQL_PASSWORD`
: The password that Guacamole will provide when connecting to PostgreSQL as
`POSTGRESQL_USER`.
If any required environment variables are omitted, you will receive an
error message in the logs, and the image will stop. You will then need
to recreate the container with the proper variables specified.
(guacamole-docker-postgresql-optional-vars)=
### Verifying the Guacamole install
Once the Guacamole image is running, Guacamole should be accessible at
{samp}`http://{HOSTNAME}:8080/guacamole/`, where `HOSTNAME` is the hostname or
address of the machine hosting Docker, and you _should_ see a login screen. If
using MySQL or PostgreSQL, the database initialization scripts will have
created a default administrative user called "`guacadmin`" with the password
"`guacadmin`". _You should log in and change your password immediately._ If
using LDAP, you should be able to log in as any valid user within your LDAP
directory.
If you cannot access Guacamole, or you do not see a login screen, check
Docker's logs using the `docker logs` command to determine if something is
wrong. Configuration parameters may have been given incorrectly, or the
database may be improperly initialized:
```console
$ docker logs some-guacamole
```

View File

@@ -1,5 +0,0 @@
# Documentation
- [API Reference](https://github.com/JoshGlazebrook/socks#api-reference)
- [Code Examples](./examples/index.md)

View File

@@ -1,17 +0,0 @@
# socks examples
## TypeScript Examples
[Connect command](typescript/connectExample.md)
[Bind command](typescript/bindExample.md)
[Associate command](typescript/associateExample.md)
## JavaScript Examples
[Connect command](javascript/connectExample.md)
[Bind command](javascript/bindExample.md)
[Associate command](javascript/associateExample.md)

View File

@@ -1,21 +0,0 @@
The MIT License (MIT)
Copyright (c) 2016 Zeit, Inc.
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

View File

@@ -1,69 +0,0 @@
# Locations table
For versions up to 3.10 see ./lnotab_notes.txt
In version 3.11 the `co_linetable` bytes object of code objects contains a compact representation of the positions returned by the `co_positions()` iterator.
The `co_linetable` consists of a sequence of location entries.
Each entry starts with a byte with the most significant bit set, followed by zero or more bytes with most significant bit unset.
Each entry contains the following information:
* The number of code units covered by this entry (length)
* The start line
* The end line
* The start column
* The end column
The first byte has the following format:
Bit 7 | Bits 3-6 | Bits 0-2
---- | ---- | ----
1 | Code | Length (in code units) - 1
The codes are enumerated in the `_PyCodeLocationInfoKind` enum.
## Variable length integer encodings
Integers are often encoded using a variable length integer encoding
### Unsigned integers (varint)
Unsigned integers are encoded in 6 bit chunks, least significant first.
Each chunk but the last has bit 6 set.
For example:
* 63 is encoded as `0x3f`
* 200 is encoded as `0x48`, `0x03`
### Signed integers (svarint)
Signed integers are encoded by converting them to unsigned integers, using the following function:
```Python
def convert(s):
if s < 0:
return ((-s)<<1) | 1
else:
return (s<<1)
```
## Location entries
The meaning of the codes and the following bytes are as follows:
Code | Meaning | Start line | End line | Start column | End column
---- | ---- | ---- | ---- | ---- | ----
0-9 | Short form | Δ 0 | Δ 0 | See below | See below
10-12 | One line form | Δ (code - 10) | Δ 0 | unsigned byte | unsigned byte
13 | No column info | Δ svarint | Δ 0 | None | None
14 | Long form | Δ svarint | Δ varint | varint | varint
15 | No location | None | None | None | None
The Δ means the value is encoded as a delta from another value:
* Start line: Delta from the previous start line, or `co_firstlineno` for the first entry.
* End line: Delta from the start line
### The short forms
Codes 0-9 are the short forms. The short form consists of two bytes, the second byte holding additional column information. The code is the start column divided by 8 (and rounded down).
* Start column: `(code*8) + ((second_byte>>4)&7)`
* End column: `start_column + (second_byte&15)`

View File

@@ -1,18 +0,0 @@
sudo apt clean
sudo apt autoremove
sudo rm /etc/ssh/ssh*host*\*
cat /etc/machine-id
sudo truncate -s 0 /etc/machine-id
sudo poweroff
Are there different license tiers or editions?
The cellular gateway (MG), camera (MV), and systems manager product lines have one tier: Enterprise.
The switch product line (MS) has two tiers: Enterprise and Advanced licensing (only for select models)
The wireless product line (MR) has two tiers: Enterprise and Advanced/Upgrade (which are described in the Cisco Umbrella Integration document).
The security/SD-WAN appliance product line (MX) has three tiers: Enterprise, Advanced Security, and Secure SD-WAN Plus, which are described in the Meraki MX Security and SD-WAN Licensing document. The virtual appliance (vMX) has three tiers: Small, Medium, and Large.
Meraki Insight (MI) has five tiers: X-Small, Small, Medium, Large, and X-Large. Details can be found in the Meraki Insight Introduction document.

View File

@@ -1,18 +0,0 @@
sudo apt clean
sudo apt autoremove
sudo rm /etc/ssh/ssh*host*\*
cat /etc/machine-id
sudo truncate -s 0 /etc/machine-id
sudo poweroff
Are there different license tiers or editions?
The cellular gateway (MG), camera (MV), and systems manager product lines have one tier: Enterprise.
The switch product line (MS) has two tiers: Enterprise and Advanced licensing (only for select models)
The wireless product line (MR) has two tiers: Enterprise and Advanced/Upgrade (which are described in the Cisco Umbrella Integration document).
The security/SD-WAN appliance product line (MX) has three tiers: Enterprise, Advanced Security, and Secure SD-WAN Plus, which are described in the Meraki MX Security and SD-WAN Licensing document. The virtual appliance (vMX) has three tiers: Small, Medium, and Large.
Meraki Insight (MI) has five tiers: X-Small, Small, Medium, Large, and X-Large. Details can be found in the Meraki Insight Introduction document.

View File

@@ -1,211 +0,0 @@
# escalade [![CI](https://github.com/lukeed/escalade/workflows/CI/badge.svg)](https://github.com/lukeed/escalade/actions) [![codecov](https://badgen.now.sh/codecov/c/github/lukeed/escalade)](https://codecov.io/gh/lukeed/escalade)
> A tiny (183B to 210B) and [fast](#benchmarks) utility to ascend parent directories
With [escalade](https://en.wikipedia.org/wiki/Escalade), you can scale parent directories until you've found what you're looking for.<br>Given an input file or directory, `escalade` will continue executing your callback function until either:
1) the callback returns a truthy value
2) `escalade` has reached the system root directory (eg, `/`)
> **Important:**<br>Please note that `escalade` only deals with direct ancestry it will not dive into parents' sibling directories.
---
**Notice:** As of v3.1.0, `escalade` now includes [Deno support](http://deno.land/x/escalade)! Please see [Deno Usage](#deno) below.
---
## Install
```
$ npm install --save escalade
```
## Modes
There are two "versions" of `escalade` available:
#### "async"
> **Node.js:** >= 8.x<br>
> **Size (gzip):** 210 bytes<br>
> **Availability:** [CommonJS](https://unpkg.com/escalade/dist/index.js), [ES Module](https://unpkg.com/escalade/dist/index.mjs)
This is the primary/default mode. It makes use of `async`/`await` and [`util.promisify`](https://nodejs.org/api/util.html#util_util_promisify_original).
#### "sync"
> **Node.js:** >= 6.x<br>
> **Size (gzip):** 183 bytes<br>
> **Availability:** [CommonJS](https://unpkg.com/escalade/sync/index.js), [ES Module](https://unpkg.com/escalade/sync/index.mjs)
This is the opt-in mode, ideal for scenarios where `async` usage cannot be supported.
## Usage
***Example Structure***
```
/Users/lukeed
└── oss
├── license
└── escalade
├── package.json
└── test
└── fixtures
├── index.js
└── foobar
└── demo.js
```
***Example Usage***
```js
//~> demo.js
import { join } from 'path';
import escalade from 'escalade';
const input = join(__dirname, 'demo.js');
// or: const input = __dirname;
const pkg = await escalade(input, (dir, names) => {
console.log('~> dir:', dir);
console.log('~> names:', names);
console.log('---');
if (names.includes('package.json')) {
// will be resolved into absolute
return 'package.json';
}
});
//~> dir: /Users/lukeed/oss/escalade/test/fixtures/foobar
//~> names: ['demo.js']
//---
//~> dir: /Users/lukeed/oss/escalade/test/fixtures
//~> names: ['index.js', 'foobar']
//---
//~> dir: /Users/lukeed/oss/escalade/test
//~> names: ['fixtures']
//---
//~> dir: /Users/lukeed/oss/escalade
//~> names: ['package.json', 'test']
//---
console.log(pkg);
//=> /Users/lukeed/oss/escalade/package.json
// Now search for "missing123.txt"
// (Assume it doesn't exist anywhere!)
const missing = await escalade(input, (dir, names) => {
console.log('~> dir:', dir);
return names.includes('missing123.txt') && 'missing123.txt';
});
//~> dir: /Users/lukeed/oss/escalade/test/fixtures/foobar
//~> dir: /Users/lukeed/oss/escalade/test/fixtures
//~> dir: /Users/lukeed/oss/escalade/test
//~> dir: /Users/lukeed/oss/escalade
//~> dir: /Users/lukeed/oss
//~> dir: /Users/lukeed
//~> dir: /Users
//~> dir: /
console.log(missing);
//=> undefined
```
> **Note:** To run the above example with "sync" mode, import from `escalade/sync` and remove the `await` keyword.
## API
### escalade(input, callback)
Returns: `string|void` or `Promise<string|void>`
When your `callback` locates a file, `escalade` will resolve/return with an absolute path.<br>
If your `callback` was never satisfied, then `escalade` will resolve/return with nothing (undefined).
> **Important:**<br>The `sync` and `async` versions share the same API.<br>The **only** difference is that `sync` is not Promise-based.
#### input
Type: `string`
The path from which to start ascending.
This may be a file or a directory path.<br>However, when `input` is a file, `escalade` will begin with its parent directory.
> **Important:** Unless given an absolute path, `input` will be resolved from `process.cwd()` location.
#### callback
Type: `Function`
The callback to execute for each ancestry level. It always is given two arguments:
1) `dir` - an absolute path of the current parent directory
2) `names` - a list (`string[]`) of contents _relative to_ the `dir` parent
> **Note:** The `names` list can contain names of files _and_ directories.
When your callback returns a _falsey_ value, then `escalade` will continue with `dir`'s parent directory, re-invoking your callback with new argument values.
When your callback returns a string, then `escalade` stops iteration immediately.<br>
If the string is an absolute path, then it's left as is. Otherwise, the string is resolved into an absolute path _from_ the `dir` that housed the satisfying condition.
> **Important:** Your `callback` can be a `Promise/AsyncFunction` when using the "async" version of `escalade`.
## Benchmarks
> Running on Node.js v10.13.0
```
# Load Time
find-up 3.891ms
escalade 0.485ms
escalade/sync 0.309ms
# Levels: 6 (target = "foo.txt"):
find-up x 24,856 ops/sec ±6.46% (55 runs sampled)
escalade x 73,084 ops/sec ±4.23% (73 runs sampled)
find-up.sync x 3,663 ops/sec ±1.12% (83 runs sampled)
escalade/sync x 9,360 ops/sec ±0.62% (88 runs sampled)
# Levels: 12 (target = "package.json"):
find-up x 29,300 ops/sec ±10.68% (70 runs sampled)
escalade x 73,685 ops/sec ± 5.66% (66 runs sampled)
find-up.sync x 1,707 ops/sec ± 0.58% (91 runs sampled)
escalade/sync x 4,667 ops/sec ± 0.68% (94 runs sampled)
# Levels: 18 (target = "missing123.txt"):
find-up x 21,818 ops/sec ±17.37% (14 runs sampled)
escalade x 67,101 ops/sec ±21.60% (20 runs sampled)
find-up.sync x 1,037 ops/sec ± 2.86% (88 runs sampled)
escalade/sync x 1,248 ops/sec ± 0.50% (93 runs sampled)
```
## Deno
As of v3.1.0, `escalade` is available on the Deno registry.
Please note that the [API](#api) is identical and that there are still [two modes](#modes) from which to choose:
```ts
// Choose "async" mode
import escalade from 'https://deno.land/escalade/async.ts';
// Choose "sync" mode
import escalade from 'https://deno.land/escalade/sync.ts';
```
> **Important:** The `allow-read` permission is required!
## Related
- [premove](https://github.com/lukeed/premove) - A tiny (247B) utility to remove items recursively
- [totalist](https://github.com/lukeed/totalist) - A tiny (195B to 224B) utility to recursively list all (total) files in a directory
- [mk-dirs](https://github.com/lukeed/mk-dirs) - A tiny (420B) utility to make a directory and its parents, recursively
## License
MIT © [Luke Edwards](https://lukeed.com)

View File

@@ -1,7 +0,0 @@
please help me with the following, I'd like for the meraki skus be provided. I need license for 1 year. I need the following:
- qty 4 MX75 with four one year Advanced Security licenses co termed
- qty 4 MS120-24 port switches with one year enterprise licenses co termed
- qty 22 MV63X cameras with one year licenses co termed
- qty 14 M22X cameras with one year licenses co termed
- qty 1 MV52 camera with a one year license co termed

View File

@@ -24,32 +24,4 @@ Admin Url: https://www.crazystorm.xyz/wp-admin/
Could you provide a comprehensive outline on the topic of being a Shopify expert and the services they provide to their clients, organized from the most important to least important aspects? Please include key points, sub-points, and any essential details within each point.
Could you provide a comprehensive outline on the topic of being a WordPress expert and the services they provide to their clients, organized from the most important to least important aspects? Please include key points, sub-points, and any essential details within each point.
slide: TBX For Winning Now and Winning Later!
GOAL
Develop and grow emerging business for Telcobuy to increase Partner diversity and maximize profits through strategic services that enable product resale and managed services for our Emerging customers.
STRATEGY
OEM Expansion: Develop key relationships with OEMS and customers to integrate new OEM support services and build on those support services to drive more $ spent through TBUY
Services Expansion: Expand both ITC and Strategic Resourcing Services within the Emerging account base. Working with BD team to develop programmatic support partnerships with OEMs and Partners.
Plan
Building relationships, running current programs and maintaining active business. Expand with key stakeholders who hold OEM relationships and channel more business through TBUY
Continue to offer Distribution Partner relevant services to compliment our Partners GTM and help them achieve faster time to revenue and more complete solutions
- Focus on:
- Building relationships.
- Maintaining current programs.
- Driving active business.
- Expand with key stakeholders who hold OEM relationships.
- Channel more business through TBUY.
- Continue to offer Distribution Partner relevant services:
- Complement our Partners' Go-To-Market (GTM) strategies.
- Help them achieve:
- Faster time to revenue.
- More complete solutions.
Could you provide a comprehensive outline on the topic of being a WordPress expert and the services they provide to their clients, organized from the most important to least important aspects? Please include key points, sub-points, and any essential details within each point.

View File

@@ -24,4 +24,32 @@ After deploying the Fortinet solutions along with the ISP services, ABC Manufact
- ABC Manufacturing's reputation as a secure and reliable business partner was strengthened, attracting new customers and driving further growth.
The combination of Fortinet's cybersecurity solutions and the ISP provider's services transformed ABC Manufacturing's digital infrastructure, making it more secure, efficient, and resilient, setting the stage for continued success and expansion in the future.
The combination of Fortinet's cybersecurity solutions and the ISP provider's services transformed ABC Manufacturing's digital infrastructure, making it more secure, efficient, and resilient, setting the stage for continued success and expansion in the future.
slide: TBX For Winning Now and Winning Later!
GOAL
Develop and grow emerging business for Telcobuy to increase Partner diversity and maximize profits through strategic services that enable product resale and managed services for our Emerging customers.
STRATEGY
OEM Expansion: Develop key relationships with OEMS and customers to integrate new OEM support services and build on those support services to drive more $ spent through TBUY
Services Expansion: Expand both ITC and Strategic Resourcing Services within the Emerging account base. Working with BD team to develop programmatic support partnerships with OEMs and Partners.
Plan
Building relationships, running current programs and maintaining active business. Expand with key stakeholders who hold OEM relationships and channel more business through TBUY
Continue to offer Distribution Partner relevant services to compliment our Partners GTM and help them achieve faster time to revenue and more complete solutions
- Focus on:
- Building relationships.
- Maintaining current programs.
- Driving active business.
- Expand with key stakeholders who hold OEM relationships.
- Channel more business through TBUY.
- Continue to offer Distribution Partner relevant services:
- Complement our Partners' Go-To-Market (GTM) strategies.
- Help them achieve:
- Faster time to revenue.
- More complete solutions.