updated README
This commit is contained in:
@@ -39,13 +39,6 @@ Firegex should not slow down the traffic on the network. For this the core of th
|
|||||||
#### 2. Availability
|
#### 2. Availability
|
||||||
Firegex **must** not become a problem for the SLA points!
|
Firegex **must** not become a problem for the SLA points!
|
||||||
This means that firegex is projected to avoid any possibility to have the service down. We know that passing all the traffic through firegex, means also that if it fails, all services go down. It's for this that firegex implements different logics to avoid this. Also, if you add a wrong filter to your services, firegex will always offer you a fast or instant way to reset it to the previous state.
|
This means that firegex is projected to avoid any possibility to have the service down. We know that passing all the traffic through firegex, means also that if it fails, all services go down. It's for this that firegex implements different logics to avoid this. Also, if you add a wrong filter to your services, firegex will always offer you a fast or instant way to reset it to the previous state.
|
||||||
1. Every reverse proxy is isolated from each other, avoiding the crash of all the proxies started by firegex
|
|
||||||
2. The proxy is a binary program written in C, started as an indipendent process with indipendent memory, and uses boost lib for the connection and the std lib for checking the regex for each packet
|
|
||||||
3. If a regex fails for whatever reason, the proxy remove this from the filter list and continue to forward the packets like it did't exist.
|
|
||||||
4. If the firewall is restarted, at the startup it try to rebuild the previous status of proxies
|
|
||||||
5. The firewall interface it's protected by a password. No one excepts your team must have access to firegex, this can be really really dangerous!
|
|
||||||
6. If a regex makes trouble, you can delete it (this have an instant effect on the proxy), or put the service in pause (also called Transparent mode), this will deactivate all the filters from the proxy, but still continue to publish the service on the right port
|
|
||||||
7. Every status change (except if you decide to stop the proxy) that you made to the service, and so to the proxy is instantaneous and done with 0 down time. The proxy is **never** restarted, it's configuration changes during runtime
|
|
||||||
|
|
||||||
# Credits
|
# Credits
|
||||||
- Copyright (c) 2007 Arash Partow (http://www.partow.net) for the base of our proxy implementation
|
- Copyright (c) 2007 Arash Partow (http://www.partow.net) for the base of our proxy implementation
|
||||||
|
|||||||
@@ -6,6 +6,6 @@ The frontend of firegex is written using create-react-app.
|
|||||||
The routing of the pages is managed by react-router 6 and the graphics is mainly managed by the framework [Mantine](https://mantine.dev) and icons provided by [React Icons](https://react-icons.github.io/react-icons/).
|
The routing of the pages is managed by react-router 6 and the graphics is mainly managed by the framework [Mantine](https://mantine.dev) and icons provided by [React Icons](https://react-icons.github.io/react-icons/).
|
||||||
The style of the page is written with [sass](https://sass-lang.com/).
|
The style of the page is written with [sass](https://sass-lang.com/).
|
||||||
|
|
||||||
The page is auto-updated by a global timeout that raise an event triggering all parts of the app that requires fetch updated data from the backend, the update of these data.
|
The page is auto-updated by a global timeout and also thanks to socket.io that raise an event triggering all parts of the app that requires fetch updated data from the backend, the update of these data.
|
||||||
|
|
||||||
## [GO BACK](../README.md)
|
## [GO BACK](../README.md)
|
||||||
Reference in New Issue
Block a user