User Details
- User Since
- Apr 12 2019, 4:27 PM (257 w, 3 d)
Yesterday
Fix to docs pending:
https://github.com/vyos/vyos-documentation/pull/1331
Well that is a fault of the docs; I will add now. Thanks !
curl -k -X POST -Fkey=baz -Fdata='{"op": "exists", "path": ["service","no","such","subpath"]}' https://192.168.122.238/retrieve|jq % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 340 100 47 100 293 547 3414 --:--:-- --:--:-- --:--:-- 4000 { "success": true, "data": false, }
@penetal does the operation 'exists' not suffice for your needs ?
Thu, Mar 14
Mon, Mar 11
Sat, Mar 9
Fri, Mar 8
Thu, Mar 7
@penetal please confirm that this is resolved.
Resolved in my tests using above reproducer; waiting for confirmation from submitter.
Wed, Mar 6
This will be resolved after merging the PR for T6104.
Tue, Mar 5
Revised PR:
https://github.com/vyos/vyos-1x/pull/3089
Note that the PR https://github.com/vyos/vyos-1x/pull/3035 is only for 1.5 at this point: the critical question for this task is whether or not to restore the simple support for unicode.
Simple unicode support was allowed in
https://vyos.dev/T3785
however, the constraint on description, above, restricts to ascii.
The short answer is that it will change going forward, and the work within this task, and the ongoing work mentioned above will avoid failing viable configs that have the symptom of 'full section of the config not applied'; that's what we are addressing here. The longer answer above attempted to distinguish several unrelated situations that have that same symptom, and in the extreme case of a user providing a corrupted, partial, or nonsensical config, there is not much that can be divined without some user feedback and suggested debugging: if critical dependencies are missing, that means that the system would be non-operational. What interests me here is some immediate improvements that may be made, and in proceeding with that, it is necessary to make these distinctions.
Mon, Mar 4
Well, nothing is deleted, rather the config section is not applied if the verification steps do not pass: if the user ignores the error and warnings and saves the subsequent working configuration, the resident config.boot file will be overwritten. So I agree that it an issue for consideration, if we distinguish those cases in which this may occur, as above. Considering those cases, we can not or would not want to (1) automatically fix migration errors, in some sense or other, to avoid non-application of config sections on migration failure; bugs in the migration system should be fixed, and improvements to the migration system itself are part of the current development plans (2) support non-verified/non-existent interfaces without clarification of when if ever that is appropriate, such as the current investigation. There is current development of the design to refine the verification stage, unrelated to this specific task. Given the preceding, I would not say either that it is a case of 'everything's fine' or of 'design flaw'; design evolution is appropriate perhaps.
Config sections not applied after failed verification is not a surprise, as discussed above, though it is understandably frustrating: warnings are provided on failure and upon entering config-mode subsequent to failure, to help avoid overwriting the saved config before investigation. As we continue this discussion we should distinguish the various issues (and I will open subtasks as appropriate):
(1) missing config sections on migration need to be debugged, as with T6076, ongoing ...
(2) verification of 'late' arriving interfaces (general); configuring ZeroTier (specific)
- I'm looking into what may be considered for the general issue, as mentioned, and I have some initial ideas; thanks to the details provided by @L0crian I'll reproduce the specific configuration for experiment
(3) support for hotplugging interfaces: not planned at the moment, but may be discussed again for 1.5
Fri, Mar 1
Thu, Feb 29
The configuration checks are the 'verify' stage of the respective config mode script; general structure here:
https://docs.vyos.io/en/sagitta/contributing/development.html#configuration-script-structure-and-behaviour
What is the content of
/tmp/vyos-configd-script-stdout ?
I raised this issue for discussion last week, and am testing more 'lenient' verification in cases such as above; I'll add results and plans here, as available.
Wed, Feb 28
PR for global solution extends the local solution in T5839:
https://github.com/vyos/vyos-1x/pull/2659
PR
https://github.com/vyos/vyos-1x/pull/2659
updated and extended for T5660.
Tue, Feb 27
Yes, this is only used by the GraphQL API.
Mon, Feb 26
Cf. the details leading to having changed this for config_op:
https://vyos.dev/T5305
Tue, Feb 20
After normalization of PR (compare with examples from T5939)
Sun, Feb 18
Forum user reports that this is resolved.
Feb 17 2024
Feb 16 2024
Simple fix here; PR pending following tests.
https://github.com/jestabro/vyos-1x/tree/pxe-boot
Feb 15 2024
This will follow from the solutions in subtask T6006.
Feb 14 2024
A general summary of the issue and proposed solution to avoid for future migrations has been added to subtask T5996, however even when implemented for 1.4 it will control, but not avoid, the problem when migrating from 1.3 --- short story: this is an incompatibility between the legacy and modern parser, and a need to refine the approach towards compatibility.
@L0crian there are no changes that would allow this in 1.4-rc1 and not 1.4-rc3 but, perhaps, for a matter of timing in bringing the interface up (see below), but if you confirm that is the case and can provide the container portion of your config, I can attempt a reproducer.
The examples in T5939 reveal a general issue that, although uncommon, needs to be rationalized. The modern parser requires single backslashes to be escaped, if in quoted strings, however (1) the legacy parser (unlike the modern parser) is inconsistent in quoting values (2) the existing solution escapes all single backslashes not a part of control sequences and makes no attempt to restore single backslashes when possible --- this is safe, but leads to redundant escaping of backslashes as revealed in the examples in T5939.
Feb 12 2024
This turns out to be non-trivial, due to the interaction between legacy and modern behavior; nonetheless, a simple preliminary fix is in testing, and the task will be updated with the details when the PR is complete.
Feb 8 2024
This is resolved in T5923; any other related concerns, reopen or open a new task.