path: root/src/vty
AgeCommit message (Collapse)AuthorFilesLines
48 hoursvty: introduce the expert mode and a command to enable itVadim Yanitskiy1-10/+35
Some VTY commands are intentionally hidden, e.g. because they might by relatively dangerous if used in production operation. We equip such commands with a special attribute - CMD_ATTR_HIDDEN. The problem is that neiter they appear in the XML VTY reference, nor in the online VTY help, so it's a bit tricky to invoke them. This change introduces so-called 'expert' mode, in which hidden (but not deprecated) commands are getting visible. In the (telnet) VTY session, this mode can be activated by passing an additional argument to well-known 'enable' command: OsmoApp> enable ? [expert-mode] Enable the expert mode (show hidden commands) OsmoApp> enable expert-mode OsmoApp# so then hidden commands will appear together with all the other commands. They will be marked with a special '^' flag: OsmoApp# list with-flags ^ ... foo-hidden [expert-mode] . ... foo-regular-one ! ... foo-immediate ^ u.. app-hidden-unbelievable For the XML reference generation, additional API needs to be introduced. This will be implemented in subsequent patches. Change-Id: Ie69c2a19b22fb31d7bd7f6412f0aeac86ea5048f Related: SYS#4910
3 dayslogging: introduce 'systemd-journal' targetVadim Yanitskiy1-0/+65
This change implements 'systemd-journal' logging target, that is similar to the existing 'syslog' target. The key difference is that 'systemd-journal' allows us to offload rendering of the meta information, such as location (file name, line number), subsystem, and logging level, to systemd. Moreover, we can attach arbitrary, user-specific fields [1] to the logging messages, so they can be used for advanced log filtering (e.g. by IMSI/TMSI/TLLI): $ journalctl OSMO_SUBSYS=DMSC -f Since we don't want to make libsystemd a required dependency, this feature is optional, and needs to be enabled at build-time: $ ./configure --enable-systemd-logging The new logging target can be configured in the same way as any other one - via the VTY interface, or using the configuration file: log systemd-journal [raw] logging level set-all notice logging filter all 1 Two logging handlers are available: generic and raw. The first one behaves similarly to both 'syslog' and 'stderr', i.e. all the meta information is rendered by libosmocore itself, and then passed to systemd together with the logging message. The later is more like the 'gsmtap' target, so all available meta information is handed over to systemd in form of fields [1]: - CODE_FILE / CODE_LINE - location info, - PRIORITY - syslog-compatible logging level, - OSMO_SUBSYS - Osmocom-specific sub-system (e.g. DMSC), - OSMO_SUBSYS_HEX - same as OSMO_SUBSYS, but encoded in hex, - MESSAGE - the logging message itself, and then can be rendered in any supported format (e.g. JSON). More details about the API can be found in [2]. [1] https://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html [2] https://www.freedesktop.org/software/systemd/man/sd-journal.html Change-Id: I609f5cf438e6ad9038d8fc95f00add6aac29fb23
10 dayscosmetic: vty: Fix trailing whitespacePau Espin Pedrol1-1/+1
Change-Id: Ieea7d13161440326d58f80f1fbc9f7e3fa5a40af
10 daysvty: Fix left shifting out of range on signed variablePau Espin Pedrol1-3/+3
Fixes following ASan runtime errors while running vty tests: src/vty/command.c:3088:27: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' src/vty/command.c:3136:23: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' Change-Id: Ie11ff18d6fd9f6e1e91a51b6156fb6b0b7d3a9a8
2020-10-08command: add library command attribute for libosmo-abisPhilipp Maier1-0/+6
Change-Id: I0efc57f2cb54798ba207ae6fef9af4771d96bfa9 Related: SYS#4937, OS#1601
2020-10-07vty: fix vty_dump_element(): do not print empty <attributes>Vadim Yanitskiy1-1/+5
Some attributes like CMD_ATTR_LIB_COMMAND are not being printed to the XML VTY reference (despite being set), so we should not print empty "<attributes scope='global'></attributes>". Change-Id: Ie7e53b080c10564bfef6f0e8ddeb470e46fad387 Related: SYS#4937
2020-10-07vty/command: restrict the use of '.', '!', and '@' as flagsVadim Yanitskiy2-0/+14
Change-Id: Icb4acbab0a15de2b0ed7b88fb0e227675317146a Related: SYS#4937
2020-10-07vty/command: assign flags to CMD_ATTR_{IMMEDIATE,NODE_EXIT}Vadim Yanitskiy1-6/+48
Change-Id: I77c1ef7ca4c667c769cc53c7ac65c3be5c7e1c86 Related: SYS#4937
2020-10-07vty/command: print attribute flags in the output of 'list'Vadim Yanitskiy1-2/+79
Here is an example: OsmoAPP(config-foo)# list with-flags ... help ... list ... show running-config ... exit ..F lib-command foo (one|two|three) ZB. lib-command bar [zoo] .bf app-command foo-bar z.. app-command zoo .TEXT ... app-command nope A dot indicates that the associated attribute is not set. Note that there is no strict relation between rows and index values of the attributes. In the example above there could be one or more hidden flag rows corresponding to attributes that are not assigned to any of the commands within 'config-foo' node. If neither of the commands belonging to the current node (where 'list' command is executed) has attributes, the output would not contain empty dot-rows. Global attributes (such as CMD_ATTR_IMMEDIATE) are not yet displayed because we still have not agreed on what kind of symbols to assign them. This will be implemented later. Change-Id: I71cef3ec0fab44c7e11fc353b8bc42268a4ee8f0 Related: SYS#4937
2020-10-07vty/command: introduce a command to list attributesVadim Yanitskiy1-0/+97
Here is an example of listing all attributes: OsmoBSC# show vty-attributes Global attributes: . This command is deprecated . This command is hidden . This command applies immediately . This command applies on VTY node exit Library specific attributes: (no attributes) Application specific attributes: o This command applies on A-bis OML link (re)establishment r This command applies on A-bis RSL link (re)establishment or only a specific kind of attributes: OsmoBSC# show vty-attributes application Application specific attributes: o This command applies on A-bis OML link (re)establishment r This command applies on A-bis RSL link (re)establishment Change-Id: I561114d7416e30cc06b7d49c0bc1217a76039c99 Related: SYS#4937
2020-10-06command: add library command attribute for libosmo-sccpPhilipp Maier1-0/+3
Change-Id: I4439a414af05700cb1ccff7e7e5927ffc194d171 Related: SYS#4937, OS#1601
2020-10-06vty/command: introduce API for the library specific attributesVadim Yanitskiy1-3/+48
See https://lists.osmocom.org/pipermail/openbsc/2020-October/013278.html. Change-Id: I15184569635b3ef7dfe9eeddcc19bf16cc358f66 Related: SYS#4937
2020-10-06vty: use install_lib_element() and install_lib_element_ve()Vadim Yanitskiy8-140/+140
See https://lists.osmocom.org/pipermail/openbsc/2020-October/013278.html. Change-Id: Ic541126ffd4975daf87199abfafb465e2055e44f Related: SYS#4937
2020-10-06vty/command: add CMD_ATTR_LIB_COMMAND and install() API wrappersVadim Yanitskiy1-0/+18
This new attribute would allow to distinguish commands provided by libraries from commands registered by the application itself, so vty_dump_element() would print proper description for the library specific attributes. All VTY commands defined by the libraries need to use the new API: - install_lib_element(), and - install_lib_element_ve, instead of the old functions (respectively): - install_element(), and - install_element_ve(). See https://lists.osmocom.org/pipermail/openbsc/2020-October/013278.html. Change-Id: I8baf31ace93c536421893c2aa4e3d9d298dcbcc6 Related: SYS#4937
2020-10-06vty/command: add global command attribute CMD_ATTR_NODE_EXITVadim Yanitskiy1-0/+1
Change-Id: I56306f4886a72a3525b60225721aa2fcf7c57213 Related: SYS#4937
2020-10-06vty: check for reserved flags in application specific attributesVadim Yanitskiy1-0/+8
We agreed to reserve uppercase flag letters for libraries. Change-Id: If0c332f7c86ff26a4060a14b947445d194a6702e Related: SYS#4937
2020-10-04vty: check for duplicate flags in application specific attributesVadim Yanitskiy1-0/+16
This would facilitate detecting duplicates on early development stages. Change-Id: I4e27d6e89d3f851b5ea4f00da01e7093afa537b2 Related: SYS#4937
2020-09-29logging_vty: set osmo_stderr_target to NULL on "no log stderr"Harald Welte1-0/+2
We cannot keep a reference to the old log_target around if we just destroyed/deleted it. Change-Id: I98a801cf83347a4422534d020d5ed5e2d1eb5482
2020-09-28vty/command: reflect global attributes in the XML referenceVadim Yanitskiy1-0/+26
Given that commands with either/both of the following attributes: - CMD_ATTR_DEPRECATED, - CMD_ATTR_HIDDEN, never end up in the XML reference, only CMD_ATTR_IMMEDIATE would be reflected for commands taking effect immediately as follows: <command id='foo'> <!-- Global attributes --> <attributes scope='global'> <attribute doc='This command applies immediately' /> </attributes> <!-- Application specific attributes --> <attributes scope='application'> <!-- ... --> </attributes> <params> <!-- ... --> </params> </command> Change-Id: I8476c1163c23a9a52641987acf3df0b8c49d8f7b Related: SYS#4937
2020-09-22vty: cosmetic: fix missing curly braces in vty_describe_command()Vadim Yanitskiy1-2/+4
Change-Id: I1585ee70a3db77aa8737f9463c4d0665f4e90d90
2020-09-22vty: cosmetic: s/width/cmd_width/g in vty_describe_command()Vadim Yanitskiy1-10/+10
Change-Id: Ifcf5f7be925c5421040d3cac2c4c5e4dd497c0f5
2020-09-22vty: cosmetic: drop redundant 'break' statementsVadim Yanitskiy1-2/+0
Change-Id: I54ee7c3c6fe16a413d0e1128c7358ff6e4b76c6a
2020-09-20vty: print program specific attributes in the XML referenceVadim Yanitskiy1-1/+26
Change-Id: I1f35368ba9178e1454f2e3ddfcad9d96576143ef Related: SYS#4937
2020-09-11vty: fix 'Unsigned compared against 0' generate_cpu_hex_mask()Vadim Yanitskiy1-1/+1
Change-Id: I49549439d5bbfbb83954ba92957304b03062d003 Fixes: CID#212137
2020-08-20vty: Fix cpu-sched VTY node namePau Espin Pedrol1-1/+1
Durin dev cycle, node was initially called "sched" instead of "cpu-sched", and when it was renamed, this specific part was missed. Change-Id: I0709fee12cc8ddc4d57efb4ea40b0b79b7ea4151
2020-08-18vty/command: cosmetic: swap i and j in vty_dump_element()Vadim Yanitskiy1-6/+6
It's more convenient to use i in the outer loop, and j, k, etc. in the inner loops. Otherwise it looks a bit confusing. Change-Id: I61ef48fcf977d6a872e288571a4ff2c3dfe3184b
2020-08-18vty/command: fix switch / case coding style in vty_go_parent()Vadim Yanitskiy1-15/+15
Change-Id: I6f7f5af6879d91811be6f0edf3feb2ebae185ac7
2020-08-17vty cpu sched: do not assert if sched impossibleEric1-2/+5
Shared code might be used by applications that have no vty, so sched can't be initialized, do not assert and break everything in this case, a warning should suffice. Change-Id: Ic40075df8d4cf9fe8f1d711f899dae9a4b5b0928
2020-08-15vty/command: cosmetic: fix formatting of config_help_cmdVadim Yanitskiy1-14/+15
Change-Id: I8f784d0cf65fa7813088e3ff76d7213b99b975d0
2020-08-15vty/command: cosmetic: simplify conditions in in config_list_cmdVadim Yanitskiy1-4/+8
Change-Id: Id1c082d102b7156dafb9c5d9197dcdc4d26bff63
2020-08-10vty: Introduce support to set cpu-affinity and scheduler policyPau Espin Pedrol2-1/+675
Process willing to support this kind of configuration through VTY simply need to call "osmo_sched_vty_init(tall_ctx);" during startup to register the commands. For multithreaded processes, new threads willing to get their cpu-affinity mask according to VTY config should call osmo_sched_vty_apply_localthread() (potentially after setting the thread name through pthread_setname_np()). Related: SYS#4986 Change-Id: If76a4bd2cc7b3c7adf5d84790a944d78be70e10a
2020-07-30vty: Don't match negative values on purely positive rangesPau Espin Pedrol1-0/+3
Without this patch, for instance having a range 0-ULONG_MAX would match if someones types value -3, which would be converted to unsigned but that's clearly what is expected here from user point of view. Change-Id: Ia95f6314a2dd3f94d21fc219cf69bb8d39b8e7f0
2020-07-30vty: Allow 64 bit values in numeric ranges if system supports itPau Espin Pedrol1-6/+22
This fixes commands not being matched due to providing a range with more than 10 digits. The last case (passing -4000 matching 0-ULONG_MAX) shows a different bug which will be fixed in next commit. Change-Id: I0afa0caabffe36083c36b92ba90696ded00bb7be
2020-07-17stats: Add stats commands related to testingDaniel Willmann1-2/+38
* Allow to set the reporting interval to 0 for manual reporting * stats reset command to reset all statistics * stats report command to manually trigger statistics reporting Change-Id: I9febcb65650abfd538caedfbca77a787e66d517a Related: SYS#4877
2020-07-15vty: Avoid ultra-long multi-line strings cluttering talloc reportsHarald Welte1-0/+6
The talloc_asprintf() series includes an unconditional call to talloc_set_name_const(), turning the entire long constructed string into the name of the talloc object. That simply doesn't work when creating kilobytes-sized VTY reference strings including linefeeds. Let's add an explicit talloc_set_name_const() to prevent this. Change-Id: Ibd77684b88cc3572047daa98c9a6b9119fba041b Closes: OS#4668
2020-05-18enable vty xml dumping to stdoutNeels Hofmeyr1-25/+60
Allow dumping the VTY XML reference (for generating manuals) to a normal FILE* stream instead of a vty output buffer. We currently generate the VTY reference by starting the client program, connecting to the VTY telnet and dumping the reference. That is weirdly convoluted, especially since there has to be a valid config file that successfully starts up a minimal set of external links before the reference can be generated. IMO we should have dumped the XML reference to stdout from the start, and never to a VTY session. With this patch, it is trivial to generate the XML VTY reference by a commandline switch. The client program will set up the entire VTY, and immediately after parsing the cmdline options but before parsing a config file, just dumps the reference and doesn't even start establishing local ports. That would allow generating the XML reference on the fly during the build process of the manuals, without the need of a docker container or somesuch. A first implementation of such a commandline switch is `osmo-bsc -X`, added in I316efedb2c1652791434ecf14a1e261367cd2fb7 This patch jumps through a bit of a hoop to still allow dumping to a VTY buffer without code dup, to still allow dumping the XML reference through telnet VTY, until all our programs have implemented an -X switch (TM). Change-Id: Ic74bbdb6dc5ea05f03c791cc70184861e39cd492
2020-05-09stats: Support regular stats flushAlexander Chemeris1-0/+26
Reliable monitoring requires regular flush of all stat values, even if they have not changed. Otherwise (1) the monitoring app has to maintain state and (2) can go out of sync if it's restarted while the app is still running. Change-Id: I04f1e7bdf0d6f20e4f15571e94191de61c47ddad
2020-05-09stats: Move cfg_stats_interval_cmd() function.Alexander Chemeris1-18/+17
cfg_stats_interval_cmd() function was (probably mistakenly) inserted between cfg_stats_reporter_statsd_cmd() and cfg_no_stats_reporter_statsd_cmd() function which makes no sense. Move it below the cfg_no_stats_reporter_log_cmd() to follow the order of the osmo_stats_vty_add_cmds() function calls. Change-Id: I1ecec7025e95cf5ffc21ae3b1c75cf6da8c58de2
2020-02-06tdef_vty: do not enforce enum 'node_type' in osmo_tdef_vty_groups_init()Vadim Yanitskiy1-3/+3
Some osmo-* applications may need to use their own VTY node as a parent for the timer configuration commands. Therefore it makes more sense to use 'unsigned int' instead of 'enum node_type'. Let's also clarify that osmo_tdef_vty_groups_init() accepts parent node for configuration commands only: 'parent_node' -> 'parent_cfg_node'. Change-Id: Ifb4c406c85d76a25fc53fc235484599aa87dc77c
2020-01-03logging_vty.c: Avoid acquiring log tgt lock in logging level cmd when not neededPau Espin Pedrol1-4/+4
Change-Id: Ia6780221174070cee408625e24513f2c11cc9dfc
2020-01-02Bump version: → Espin Pedrol1-1/+1
Change-Id: I5698bfe45467a8b0e44549105aaf27b8da500de8
2019-11-30libosmovty: simplify condition checking vty->fd in vty_close()Vadim Yanitskiy1-2/+2
On POSIX systems, standard I/O streams - stdin, stdout, and stderr, always have default file descriptors 0, 1, and 2 respectively. Change-Id: Ied35d142af0ba0f5ad78975b8f22c35b32d6ff71
2019-11-30libosmovty: properly initialize vty->fd in vty_new()Vadim Yanitskiy1-0/+1
Since we're using talloc_zero(), vty->fd is initialized with 0, which corresponds to stdin. Let's set an invalid value to prevent potential bugs like the one fixed by the recent change [1]. [1] Icdeaea67a06da3a2f07b252e455629559ecc1829 Change-Id: Iec15649781317a23e13d2c2840a8f672050f76c1
2019-11-24vty: track parent nodes also for telnet sessionsNeels Hofmeyr1-30/+24
Keep track of parent nodes and go back hierarchically, not only for .cfg file reading, but also for telnet VTY sessions. A long time ago cfg file parsing was made strictly hierarchical: node exits go back to parent nodes exactly as they were entered. However, live telnet VTY sessions still lacked this and depended on the go_parent_cb(). From this commit on, implementing a go_parent_cb() is completely optional. The go_parent_cb() no longer has the task to determine the correct parent node, neither for cfg files (as already the case before this patch) nor for telnet VTY sessions (added by this patch). Instead, a go_parent_cb() implementation can merely take actions it requires on node exits, for example applying some config when leaving a specific node. The node value that is returned by the go_parent_cb() and the vty->node and vty->index values that might be set are completely ignored; instead the implicit parent node tracking determines the parent and node object. As a side effect, the is_config_node() callback is no longer needed, since the VTY now always implicitly knows when to exit back to the CONFIG_NODE. For example, osmo_ss7_is_config_node() could now be dropped, and the osmo_ss7_vty_go_parent() could be shortened by five switch cases, does no longer need to set vty->node nor vty->index and could thus be shortened to: int osmo_ss7_vty_go_parent(struct vty *vty) { struct osmo_ss7_asp *asp; struct osmo_xua_server *oxs; switch (vty->node) { case L_CS7_ASP_NODE: asp = vty->index; /* If no local addr was set */ if (!asp->cfg.local.host_cnt) { asp->cfg.local.host[0] = NULL; asp->cfg.local.host_cnt = 1; } osmo_ss7_asp_restart(asp); break; case L_CS7_XUA_NODE: oxs = vty->index; /* If no local addr was set, or erased after _create(): */ if (!oxs->cfg.local.host_cnt) osmo_ss7_xua_server_set_local_host(oxs, NULL); if (osmo_ss7_xua_server_bind(oxs) < 0) vty_out(vty, "%% Unable to bind xUA server to IP(s)%s", VTY_NEWLINE); break; } return 0; } Before parent tracking, every program was required to write a go_parent_cb() which has to return every node's parent node, basically a switch() statement that manually traces the way back out of child nodes. If the go_parent_cb() has errors, we may wildly jump around the node tree: a common error is to jump right out to the top config node with one exit, even though we were N levels deep. This kind of error has been eliminated for cfg files long ago, but still exists for telnet VTY sessions, which this patch fixes. This came up when I was adding multi-level config nodes to osmo-hlr to support Distributed GSM / remote MS lookup: the config file worked fine, while vty node tests failed to exit to the correct nodes. Change-Id: I2b32b4fe20732728db6e9cdac7e484d96ab86dc5
2019-11-21logging/vty: fix: do not close stderr in vty_close()Vadim Yanitskiy1-1/+1
Since Icdeaea67a06da3a2f07b252e455629559ecc1829, we use stderr for printing warnings while parsing the VTY configuration files. Make sure we do not close() stderr. Otherwise stderr logging gets broken. Change-Id: I6ecc85555d102f5911d50ed5ac54933c766fa84d Fixes: Icdeaea67a06da3a2f07b252e455629559ecc1829
2019-11-21logging/vty: fix vty_read_file(): do not write warnings to stdinVadim Yanitskiy1-1/+5
Setting vty->fd to 0 is a bad idea, which may cause the process to write() warnings to its own _stdin_ (yes, it's possible). For example, when a configuration file contains deprecated logging commands. Let's use stderr by default. Change-Id: Icdeaea67a06da3a2f07b252e455629559ecc1829
2019-11-21logging/vty: fix: actually ignore deprecated logging commandsVadim Yanitskiy1-1/+1
We shall not prevent programs from starting if their configuration files contain deprecated 'logging level ...' commands. Just print a warning and return CMD_SUCCESS instead of CMD_WARNING. While writing a unit test, another funny bug has been uncovered. Parsing of a deprecated command indeed triggers a deprecation warning, originated from libosmovty's log_deprecated_func(). This function simply calls vty_out(), but... Since the invocation of the vty_out() happens _before_ the VTY is initialized, the process is actually writing that warning to its own stdin! Most likely, because we use talloc_zero() to allocate a new instance of struct 'vty'. As a side effect, the evil warning magically appears in the output of 'make check', breaking the test statistics. Let's work around this bug for now by redirecting stdin to /dev/null. Change-Id: Ia934581410cd41594791d4e14ee74c16abe1009a Fixes: Ic9c1b566ec4a459f03e6319cf369691903cf9d00
2019-11-21logging/vty: use LOG_LEVEL_ARGS in logging_vty_add_deprecated_subsys()Vadim Yanitskiy1-2/+1
Change-Id: I862c3cce0147ee8cf4013501132584ea09c58b53
2019-11-20logging/vty: do not print deprecated logging commands to stdoutVadim Yanitskiy1-1/+0
Yes, we don't really need to poison stdout, as some osmo-* binaries (like osmo-gapk) may want to use it for non-logging purposes. This printf() call looks like a debugging leftover. Change-Id: Ida35865b1c0bb3d3567918f8e89c6551c6b34103
2019-10-28vty: Return error if cmd returns CMD_WARNING while reading cfg filePau Espin Pedrol1-2/+1
Otherwise bad configurations can easily sneak in and produce unexpected behavior. Change-Id: Ic9c1b566ec4a459f03e6319cf369691903cf9d00