In creative mode, please fix the mod so that it can fit in the box by dragging the shulker box with the mouse while pressing down the key

In creative mode, please fix the mod so that it can fit in the box by dragging the shulker box with the mouse while pressing down the key

There are two types of creative inventories: the "Creative Inventory" (the one with tabs from which you can take unlimited items) and the "Creative Survival Inventory" (the one where you can equip armor). The problem is that the first one is quite old, I would even call it legacy. Back in the day, some genius decided to implement it almost entirely on the client-side, and since Packed Inventory is a server-side mod (except for the keybindings, which are created to send commands to the server), it's impossible for it to manipulate or even recognize a client-side inventory. To "fix" this issue, I would need to fix Minecraft itself, specifically its legacy code. And I firmly believe that this is beyond the scope of this mod. Especially when users can easily switch to the Creative Survival Inventory (by pressing the chest icon in the regular creative inventory), which is server-side and therefore already compatible with Packed Inventory.


Error using tensorflow module, even appearing in the list shown by pip list

Please make sure that this is a build/installation issue. As per our GitHub Policy, we only address code/doc bugs, performance issues, feature requests and build/installation issues on GitHub. tag:build_template
System information

OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Windows 10
TensorFlow installed from (source or binary): source
TensorFlow version:
Python version: 3.7.3
Installed using virtualenv? pip? conda?: pip
GPU model and memory: MX920

Describe the problem
I can't use tensorflow module, even appearing in the list shown by pip list
Provide the exact sequence of commands / steps that you executed before running into the problem
I executed the 3 first commands:
python3 --version
pip3 --version
virtualenv --version
But, the answer I get from the 1st command was: "python3" is not recognized as a intern or extern command, operational program or a batch file
Then I just keep with the installation, because the virtualenv and the pip3 were updated, and after that, I tried to do the command:
virtualenv --system-site-packages -p python3 ./venv
But the answer I get was:
The path python3 (from --python=python3) does not exist
so, I couldn't create the virtual environment.
After that, I wrote the command:
pip3 install --user --upgrade tensorflow
And the command:
pip list
In the answer of the last one, the list showed that the tensorflow was installed, but when I tried to run an example provided by the TensorFlow site, PyCharm couldn't find the module, and now I don't know what to do.
Also, when I write the command:
python -c "import tensorflow as tf; tf.enable_eager_execution(); print(tf.reduce_sum(tf.random_normal([1000, 1000])))"
I get this answer:
2019-05-13 21:40:50.182555: I tensorflow/core/platform/cpu_feature_guard.cc:141] Your CPU supports instructions that this TensorFlow binary was not compiled to use: AVX2
tf.Tensor(1277.5322, shape=(), dtype=float32)

@wagnerDestro Please follow the instructions in this link to install tensorflow. Thanks!

@gadagashwini I followed the steps in the tensorflow guide. I even reinstalled Python 3 to make sure, but the error persists.

@wagnerDestro Can you recheck and confirm that your cpu supports AVX2?

Automatically closing due to lack of recent activity. Please update the issue when new information becomes available, and we will reopen the issue. Thanks!


The search settings widget is obstructed by the sticky scroll

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.71.0
OS Version: Windows_NT x64 10.0.19043

Steps to Reproduce:

Press AltC (or your hotkey for toggleFindCaseSensitive)
Observe this thingie popping up in the top-right corner of the editor:

Now enable the sticky scroll and press the hotkey again.
Observe that this widget isn't visible anymore. Apparently, the sticky scroll is displayed on top of it.

The search settings widget should be displayed on top of the sticky scroll, not the other way around.

Duplicate of #159034

Duplicate of https://github.com/microsoft/vscode/issues/159034


update solidity interfaces and algorithm

Updates the Solidity interfaces based on things we've discussed:

Note that the Generator contract is mainly a reference and you shouldn't use it unless using your own node to call it.
Spending and viewing public keys are explicitly part of the spec as agreed upon in https://github.com/nerolation/EIP-Stealth-Address-ERC/pull/2#discussion_r1009760585
The shared secret is directly used to compute the stealth address, as specified in DKSAP section of this article
Removes the sharedSecretHash parameter from generateStealthAddress. There is now a discrepancy: the view tag is specified as 32 bytes in the return parameter, but in the Announcement event it's spec'd as being 12 bytes to pack with the stealth address. Is the complexity (for e.g. frontends) of packing stealthRecipientAndViewTag instead of separating them as two different params worth the small gas savings? I think I lean towards separating them out as distinct parameters and using a 32 byte view tag—the added gas cost will be small and the simpler we can make the spec the more likely it is to gain adoption

And one new thing which I don't think we've discussed:

Updates registerKeysOnBehalf to take the signatures as bytes and requires supporting EIP-1271.

This PR does not make significant changes to other parts of the EIP. Planning to review the rest of it later this week

What do you think about the procy-like fallback function that can be used for any arbitrarly transaction:
I'm thinking about EOAs that want to do a stealth "approve" by approving tokens to be spend by a certain stealth address.
Those would need to either create two separate txs, or we add a fallback function that acts like a proxy and forwards commands.


chore(readme): add comma

Tiny fix; just adding a comma that needed to be there.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

My pleasure


Misleading documentation (feat. not yet released)

Describe the bug
Documentation site describes permittedInsecurePackages as a valid devenv.yaml key.
Presumably the documentation got updated when https://github.com/cachix/devenv/pull/638 got merged, but since there's been no release since the PR was merged, the documentation is misleading.
Version
devenv: 0.6.2

Released v0.6.3, thanks!

Released v0.6.3, thanks!

I don't see v0.6.3 anywhere


PKG-4714 initial v12.4

Destination channel: defaults
Links

PKG-4714

Explanation of changes:

Part of CUDA 12.4 build, following conda-forge's pattern which was developed in conjunction with Nvidia. I don't see a need to stage these then release them all at once. They won't cause a problem released one at a time.
Please check the main branch too, this has just been forked
Changes made to adjust feedstocks for differences between conda-forge and defaults. Please see commit messages for description of changes.

Linter check found the following problems:
ERROR conda.cli.main_run:execute(124): `conda run conda-lint /tmp/abs_4bx2wrx50r/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:35: license_file_overspecified: Using license_file and license_url is overspecified.

===== ERRORS =====

clone/recipe/meta.yaml:35: missing_dev_url: The recipe is missing a dev_url
clone/recipe/meta.yaml:35: missing_license_family: The recipe is missing the about/license_family key.
===== Final Report: =====
2 Errors and 1 Warning were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_988u9v5sjq/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:35: license_file_overspecified: Using license_file and license_url is overspecified.

===== ERRORS =====

clone/recipe/meta.yaml:35: missing_dev_url: The recipe is missing a dev_url
clone/recipe/meta.yaml:35: missing_license_family: The recipe is missing the about/license_family key.
===== Final Report: =====
2 Errors and 1 Warning were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_b675bool3j/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:35: license_file_overspecified: Using license_file and license_url is overspecified.

===== ERRORS =====

clone/recipe/meta.yaml:35: missing_license_family: The recipe is missing the about/license_family key.
clone/recipe/meta.yaml:35: missing_dev_url: The recipe is missing a dev_url
===== Final Report: =====
2 Errors and 1 Warning were found


Dagger module cannot install CLI

I want to use the Dagger Module to install CLI in order to create a publish module.
However I have an error when I try to install the CLI.
Repro
dagger mod use github.com/shykes/daggerverse/dagger

	_, err := dag.Dagger().Engine().Release("0.9.3").Source().Cli().Sync(ctx)
	if err != nil {
		return err
	}

✘ exec /runtime ERROR [2.47s]
┃ json: error calling MarshalJSON for type *main.File: input:1: container.from.withExec.withEnvVariable.withExec.withWorkdir.withDirectory.withMountedCache.withExec.withMountedDirect
┃ y.withMountedCache.withExec.file process "go build -o ./bin/dagger -ldflags -s -w -X github.com/dagger/dagger/engine.EngineImageRepo=registry.dagger.io/engine ./cmd/dagger" did not
┃ omplete successfully: exit code: 1
✘ file(path: "./bin/dagger") ERROR [1.07s]
✘ exec go build -o ./bin/dagger -ldflags -s -w -X github.com/dagger/dagger/engine.EngineImageRepo=registry.dagger.io/engine ./cmd/dagger ERROR [0.27s]
┃ /go/pkg/mod/github.com/dagger/graphql@v0.0.0-20231103002502-b36795bcf171/introspection.go:6:2: package slices is not in GOROOT (/usr/local/go/src/slices)
• Engine: a88d9134bd86 (version devel ())

I'll try to find a fix, it might be fixed by that, I need to check.

It works using 0.9.2, we added slice package in 0.9.3 but it doens't look available in the standard golang alpine library


Add security section

Add Security section.
Current plan based from https://aka.ms/aks/secure

Hey 👋
I looked into the linked repo. Having all those tips is great.
However, I think a dedicated ServiceAccount with limited or no access to k8s apiserver would be essential to mention for a security guide.


[Refactor] iceberg and paimon table adapt to partition prune

Fixes #issue
What type of PR is this:

[ ] BugFix
[ ] Feature
[ ] Enhancement
[x] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Does this PR entail a change in behavior?

[ ] Yes, this PR will result in a change in behavior.
[x] No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

[ ] Interface/UI changes: syntax, type conversion, expression evaluation, display information
[ ] Parameter changes: default values, similar parameters but with different default values
[ ] Policy changes: use new policy to replace old one, functionality automatically enabled
[ ] Feature removed
[ ] Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[ ] I have checked the version labels which the pr will be auto-backported to the target branch

[ ] 3.2
[ ] 3.1
[ ] 3.0
[ ] 2.5

[FE Incremental Coverage Report]
:disappointed: fail : 16 / 54 (29.63%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/connector/iceberg/IcebergMetadata.java
0
1
00.00%
[318]

:large_blue_circle:
com/starrocks/sql/optimizer/statistics/StatisticsCalculator.java
0
2
00.00%
[290, 359]

:large_blue_circle:
com/starrocks/connector/unified/UnifiedMetadata.java
0
1
00.00%
[149]

:large_blue_circle:
com/starrocks/sql/optimizer/rewrite/OptExternalPartitionPruner.java
12
46
26.09%
[316, 327, 328, 329, 330, 331, 332, 333, 335, 336, 338, 339, 342, 343, 345, 346, 347, 350, 351, 352, 353, 354, 355, 356, 357, 360, 361, 362, 364, 365, 366, 368, 369, 370]

:large_blue_circle:
com/starrocks/server/MetadataMgr.java
2
2
100.00%
[]

:large_blue_circle:
com/starrocks/connector/iceberg/cost/IcebergStatisticProvider.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/connector/CatalogConnectorMetadata.java
1
1
100.00%
[]

[BE Incremental Coverage Report]
:heart_eyes: pass : 0 / 0 (0%)

[BE Incremental Coverage Report]
:heart_eyes: pass : 0 / 0 (0%)

[BE Incremental Coverage Report]
:heart_eyes: pass : 0 / 0 (0%)

[FE Incremental Coverage Report]
:heart_eyes: pass : 44 / 54 (81.48%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/connector/iceberg/IcebergMetadata.java
0
1
00.00%
[318]

:large_blue_circle:
com/starrocks/sql/optimizer/statistics/StatisticsCalculator.java
0
2
00.00%
[290, 359]

:large_blue_circle:
com/starrocks/connector/unified/UnifiedMetadata.java
0
1
00.00%
[149]

:large_blue_circle:
com/starrocks/sql/optimizer/rewrite/OptExternalPartitionPruner.java
40
46
86.96%
[316, 336, 339, 357, 362, 366]

:large_blue_circle:
com/starrocks/server/MetadataMgr.java
2
2
100.00%
[]

:large_blue_circle:
com/starrocks/connector/iceberg/cost/IcebergStatisticProvider.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/connector/CatalogConnectorMetadata.java
1
1
100.00%
[]


Breaking changes

As of bb66dc961520a6513faf6d961609f8746497dcbf, the leap function expects a list of winids instead of wininfo tables as the target-windows argument. See the updated snippets in the README.

518389452cfb65d0493c134c58675cdeddbeb371 changed the flag case_insensitive to case_sensitive (with default false).

97ab70a97dc36b8440916daab1fa2f1fc6dcb98c changes all arguments of the leap function and all fields of the (so far undocumented) state table (i.e., the user-facing API) to snake case, to ease usage in plain Lua. For most people the relevant change is ['target-windows'] = ... -> target_windows = ....

As of 235ad9d50ed290e8f770eef580cb07c5bd87c8c5 opts.max_aot_targets replaces opts.highlight_ahead_of_time. This is nalogous to our "smart" autojump feature - instead of using a binary flag, ahead-of-time displaying of target beacons can be enabled conditionally, for a certain maximum number of phase 1 targets. Setting it to nil corresponds to the old flag's true state, while setting it to 0 corresponds to false.

539d6e6936462a4685bd6c895ce46b5ff1c1826b removed special_keys.eol. If you want to set an alias for \n, simply define a character class that contains it, e.g. "\r\n" (or {'\r', '\n'}) if you want to use <enter>.

860e2d3941f6b13b8da0b62fd75d9209cb603f22 renamed the opts field character_classes to equivalence_classes.

5f4d67cf4838be55b42eefd0d0ebeab2b79f4da7: nil or false cannot be used anymore to mark labels and safe_labels "disabled". (This flexibility provided practically zero value for users, while making our lives unnecessarily harder.)

Not a breaking change (yet), but a deprecation notice: 937bc9280f0073df16e355887bf5f199cff4ec92 replaced set_default_keymaps() with add_default_mappings() (applying a new mapping scheme), and the most of the old <Plug> keys with new ones. See more info in the docs.

9cc411481db859059ad66c8ad844b9386dc62d5c renamed a bunch of fields in opts and opts.special_keys. See the rationale in the commit message.

Deprecation notice: setup is not recommended to use from now on - set the opts fields directly. Instead of setup, it is possible that we'll expose a convenience function under the name configure or something like that in the future.

6068651f7f2bdb379344de52b9833d82bce27cec renamed <Plug>(leap-cross-window) to <Plug>(leap-from-window).

3cc0e6a0b99dc18d4e5a88baa3cbe3c7b8b34566: special_keys.next_target takes the role of repeat_search and next_phase_one_target too now. See the commit message for details.

Deprecation notice: new default mappings, hopefully for the last time: https://github.com/ggandor/leap.nvim/commit/88c627eb935e3c4ac2ab543c8a702e883072f669. The -till/-to <Plug> keys are still documented, and the old mapping arrangement is suggested as an alternative one.

03bf7a3: accessing leap.state is deprecated - to get the arguments of the current leap() call in autocommand callbacks, use event.data.args (see :h leap-events).

ce16fae: multiselect mode has been removed.

d74388c: fix: event.data.args is a callback now (:h leap-events).

https://github.com/ggandor/leap.nvim/commit/b75a86f14ebdb3940460bfd1a02224210eccc698 simplified the highlighting logic. LeapLabelPrimary is kept as an alias for the new, generic LeapLabel group, but deprecated, and should be renamed if possible.


fix: added missing method in IMetasysClient

Changes
IMetasysClient is missing Task<IEnumerable<MetasysObject>> GetObjectsAsync(Guid objectId, string objectType); method which was added in this https://github.com/metasys-server/basic-services-dotnet/pull/122/commits/305256fd654f331a632a79d2ce218e20d0367544 commit.
I guess it was removed in this commit  https://github.com/metasys-server/basic-services-dotnet/pull/124/commits/08190f35b074e3db9e99125f3a29c3189902168a by mistakenly.
Reviewer
@jsharmbh @hicksjacobp @Federico-Artioli

I just think the version needs to be bumped.

Bumped the version to get the new nuget. It needed to further make changes in Pvt scan engine.
FYI @Federico-Artioli


Improved DB File Access

This PR addresses problems that occur when building a binary of both example applications while using the SQLite drivers and database. The issue arises from variations in the file locations found in dev versus prod modes:

in dev things were working but that's because the CWD is set to examples/[xxx]/tauri-src and the database is created there using the migrations feature
in prod the "app directory" should be used joined with the filename passed in to create a full path
finally, at least in macOS, when the app is installed it is assigned an "app directory" but this directory is not created and must be before SQLx is told to create a database at the given path

Current State
This implementation is working with the exception of the migrations feature. When you run prod or dev, it will ensure that the directory is created as well as the database but because migrations are still running on the non-adjusted file path it does not create the "todos" table and therefore operations will fail.
I'm imagining two possible solutions to this last hurdle which I'll highlight below.
Review
I am looking forward to your review comments and please do "let me have it" ... I am doing this to learn and this is pretty close to the first Rust program I've compiled (I briefly created an Actix server many months ago).
Other Stuff
The goal for this PR has been stated but be aware that I did make small adjustments on the frontend, including:

brought in eslint file from Tauri CLI
improved inline API documentation and used multi-line comments to promote the types to consumers
probably some other small things I'm forgetting about

Having read through the comments, I think the one advantage of path_mapper is that the translation between the user provided DB file path and the fully qualified one is only done once but in it's current implementation is both adds extra complexity and also makes it so none of the command signatures pull down the AppHandle. Of course, on this second point, it's not inherantly important that any command receive AppHandle outside of it being illustrative to other future authors or people using the plugin for instruction to see an example of taking this valuable resource in.
So, that said, I think my next step should be to recreate a path_mapper which can be used in both load and initialize but in general use the AppHandle directly in both functions. I'll try a pass at this today.

Ok, everything appears to work now and I believe I've incorporated all your comments from last time. Let me know if this commit passes muster. Also, thanks so much for all your help. I feel like I learned a ton.

@lucasfernog I believe this should be ready for you to review for sign-off. The plugin now successfully places the database files into the app's directory on macOS making both "dev mode" and production binaries work for the Vue TODO app and I presume the Svelte one too.

I haven't tested on Linux and Windows but probably will do that today.

@lucasfernog just wanted to check if you'd had a chance to review this. Obviously its the holidays so not expecting a fast turn around. BTW, the one failed CI/CD check is a permissions issue but clippy doesn't report any issues for me.

Thanks for this PR @ksnyde amazing work!

Thanks guys. Happy new year to you both!

Thanks guys. Happy new year to you both!

I don't have rights to merge this; can someone help me get this merged in?

yeah tbh, the permissions are kinda messed up on the plugin repos. Can't even close issues 😅
I mean it does make sense not to automatically give everyone write (or triage) rights in every new repo, but i also don't feel like requesting it everytime haha

Sorry guys I was waiting on CI and forgot to merge this. We're fixing the repo permissions too. Thanks for your effort!

Cool and thanks. This may not be what you wished for in the new year but I have another PR that I can push up later today. :)


Fix #196, Add Testing Tools to the Security Policy

Describe the contribution
Fix #196
Updated the Security Policy to include the type of testing done for cFS under a new section titled "Testing". Provided a disclaimer that under the Apache license, liability is not provided.
Expected behavior changes
Users should now be aware of the type of testing cFS undergoes.
Additional context
References:
https://github.com/thanos-io/thanos/security/policy
https://github.com/phpMussel/phpMussel/security/policy
https://github.com/timberio/vector/security/policy
Contributor Info - All information REQUIRED for consideration of pull request
Ariel Adams, ASRC Federal

Rename title to reflect the change. "Update" is too vague.

Probably to update the Issue title first

Updated the issue and PR titled. Added links to the GitHub Actions workflows, results, and where to find additional information for each testing tool.

Added a new section titled "Security Reports". Instructed users to email us at<EMAIL_ADDRESS>to submit security reports and findings.

The security policy is completed.


removed fast furnaces and now there is no furnace texture

I removed the fast furnace mod and when i did it removed the furnace texture

You'll have to break and replace all furnaces in-world, or reinstall it.


Update cfn_lint dependency

Overview
This updates cfn_lint from 0.13.0 to 0.23.3, so that linting works for newly supported services, such as Amazon Managed Blockchain.
Testing/Steps taken to ensure quality
I ran python setup.py test both before and after my changes and saw no alteration in the results. However, I am experiencing a broken test that appears to be unrelated:
test_genaz_raises_taskcat_exception (test_template_params.TestParamGen) ... [ERROR  ] :!Only 1 az's are available in us-east-1

I submitted this as Issue #321.

Merging to pull in AWS::ManagedBlockchain support.
Don't see any issues with the version updates


Initial Tokenizing and parsing into Expressions

This is not related to the new code, but I missed this during the last "review". I'm writing it down so that I don't forget about it.
For semantic equality, it is not necessarily valid to return false when self_literals != other_literals. Counterexample: a & b & (c | !c) is semantically equivalent to a & b.

Discussion question: How hard would it be to have a position in the original string associated with each error? I'm guessing we'll need to add some kind of position field to each token and then we can report that? Motivation: I can print "Error is here", not just "there is an error".

This is not related to the new code, but I missed this during the last "review". I'm writing it down so that I don't forget about it.
For semantic equality, it is not necessarily valid to return false when self_literals != other_literals. Counterexample: a & b & (c | !c) is semantically equivalent to a & b.

Very good point, will fix :+1:

Discussion question: How hard would it be to have a position in the original string associated with each error? I'm guessing we'll need to add some kind of position field to each token and then we can report that? Motivation: I can print "Error is here", not just "there is an error".

Not hard at all, the thiserror crate is quite powerful (it's just that the documentation is a bit sparse). Will fix!

For discussion:

how to reconcile multi-char variable names
how to reconcile multi-char operator names

having "false" as an operator prevents "false" to be used as a substring anywhere in variables, same goes for F or not...
having both & and && operators results in parsing "a && b" as "a and and b"

@daemontus After yesterdays changes, I added some tests to increase coverage.
Could you please re-review before we merge this?

One more thing, and then I believe we are done :)
We need some kind of generic "UnknownSymbol" token error. Right now, parsing something like "@", or "and$", or "" just loops forever, because we detect an empty literal and cannot move to the next character. I think it should be sufficient to have an emptiness check in consume_while_literal and throw the "UnknownSymbol" error there. Or alternatively put it in the main match expression in the tokenize_level function.


Add Ubuntu 22.04 codename jammy

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Thank you @robkooper!


Python API Stability

I understand that bumpver is primarily a CLI tool, but I would like to try and use the Python API for scripting a more complex situation of bumping multiple versions in a monorepo.
Is there any guarantees on the internal API? Or maybe a weaker statement of it changes much etc. would help me evaluate this choice.

No guarantees for API stability so far. If you're willing to write unit tests against the API you will be using, I think I can make a commitment regarding stability. So far the tests I've written are mostly end-to-end integration tests.
Perhaps you can start by sketching out which functions you'd be calling. I'd assume you'll be working with bumpver.v2version:incr and bumpver.v2rewrite:rewrite_files. You can look at usage of them in bumpver.cli.

I have a similar situation in which I am planning to use bumpver. Thanks for the pointer @mbarkhau might make sense for the future to keep that in mind (API usage).
And thanks for the lovely work!


As a user whose account has been deactivated, I need to know why I can't log in to SE so that I can find out how to regain access

If the user does have an account but the account is not active ("Active" is unchecked), they get a 405 error:

(FWIW, if the user had an account, was deactivated and getting the 405 error, and then has their account fully deleted, it does go back to just giving them "Permission denied" 403 error--tested this with my sponsored account)
Give them same message they get with 403 error.

Ok so I am not positive (be gentle, I'm inexperienced) but I think that we would need to add in logic that doesn't already exist to use this new template or use the 403.html template (I would want it to be the exact same, so if possible, using the 403.html template would be ideal). The reason I'm thinking this is because this resource on Django seems to be saying that the error views that we have now are all sort-of default, and automatically point to the appropriate template name. However, there isn't a built in one for a 405 error.
@jonespm @zqian when you have time, would you mind advising on this?
The actual messages that are displaying are coming from the following code in index.html lines 117-129:

            {% if messages %}

                    {% for message in messages %}

                            <button type="button" class="close" data-dismiss="alert" aria-label="Close">
                                ×
                            </button>
                            {{ message }}

                    {% endfor %}

            {% endif %}

Yeah dealing with the 405 will take more work. Looks like maybe this solution I can look at getting that to work, just provide the template! (Can just call it 405.html in that same folder)
https://stackoverflow.com/a/4634795/3708872

@mfldavidson I committed your html file and made the middleware change live on dev. Looks like it's working to me, can you test it? I'll work on a PR for it.

Testing in dev. I'm getting stuck as I try to log in. Admin console is recording that the user logged in but I'm not getting properly redirected. I'll send the video to you in another channel in case it's a security issue.

To recap convo we just had in person: testing new fix has gone pretty well, but still encountering these issues:

Takes too long to redirect user/load page
Any attempts to redirect several times (either reloading page a bunch or clicking around on things like "My Students" or search leads to getting stuck at https://shib-idp-test.www.umich.edu/idp/profile/SAML2/POST/SSO
Clicking "login" after getting redirected to the error page gives the user the same "This page isn’t working If the problem continues, contact the site owner. HTTP ERROR 405" message that we are trying to fix with this issue.

Some of that delay might be because of shibboleth test. Not sure how we can
tell but I'll see if I can think of something
I'll look at the login link after permission denied though. Thanks!
On Fri, Apr 5, 2019, 1:01 PM Maggie Davidson<EMAIL_ADDRESS>wrote:

To recap convo we just had in person: testing new fix has gone pretty
well, but still encountering these issues:

Takes too long to redirect user/load page
Any attempts to redirect several times (either reloading page a
bunch or clicking around on things like "My Students" or search leads to
getting stuck at
https://shib-idp-test.www.umich.edu/idp/profile/SAML2/POST/SSO
Clicking "login" after getting redirected to the error page gives
the user the same "This page isn’t working If the problem continues,
contact the site owner. HTTP ERROR 405" message that we are trying to fix
with this issue.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/tl-its-umich-edu/student_explorer/issues/90#issuecomment-480349351,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABrN7M701V46nhuZYS50XuTo8bFe7itks5vd4FngaJpZM4cMQ8E
.

I think I fixed your 3rd bullet point (and possibly second on dev) with a recent commit. Going to merge that PR so we can test it all.


flux-local build failes for helm OCI chart

flux-local works perfectly for our use cases, but I cannot get flux-local build  --enable-helm working when I have a helm chart which is oci hosted in my config.
Example:
I followed the install instructions for the weaveworks-gitops dashboard which leaves me with the following resources:
---
apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: HelmRepository
metadata:
 annotations:
   metadata.weave.works/description: This is the source location for the Weave GitOps
     Dashboard's helm chart.
 labels:
   app.kubernetes.io/component: ui
   app.kubernetes.io/created-by: weave-gitops-cli
   app.kubernetes.io/name: weave-gitops-dashboard
   app.kubernetes.io/part-of: weave-gitops
 name: ww-gitops
 namespace: flux-system
spec:
 interval: 1h0m0s
 type: oci
 url: oci://ghcr.io/weaveworks/charts
---
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
 annotations:
   metadata.weave.works/description: This is the Weave GitOps Dashboard.  It provides
     a simple way to get insights into your GitOps workloads.
 name: ww-gitops
 namespace: flux-system
spec:
 chart:
   spec:
     chart: weave-gitops
     sourceRef:
       kind: HelmRepository
       name: ww-gitops
 interval: 1h0m0s
 values:
   adminUser:
     create: true
     passwordHash: <hash>
     username: admin

with this HelmRelease in my flux kustomization
flux-local build ./clusters/<clustername> --enable-helm --skip-crds

failes with the following error:
flux-local error:  Invalid <class 'flux_local.manifest.HelmChart'> missing sourceRef fields: {'apiVersion': 'helm.toolkit.fluxcd.io/v2beta1', 'kind': 'HelmRelease', 'metadata': {'name': 'ww-gitops', 'namespace': 'flux-system', 'annotations': {'config.kubernetes.io/index': '0', 'internal.config.kubernetes.io/index': '0'}}, 'spec': {'chart': {'spec': {'chart': 'weave-gitops', 'sourceRef': {'kind': 'HelmRepository', 'name': 'ww-gitops'}}}, 'interval': '1h0m0s', 'releaseName': 'ww-gitops'}}

It seems like this  error happens because of a missing namespace key under spec.chart.spec.sourceRef.
When I add the namespace key like namespace: flux-system I get another error:
Command '(None) helm template ww-gitops flux-system-ww-gitops/weave-gitops --namespace flux-system --skip-tests --values /var/folders/tj/25qdsj_n1bqfr1bwvj9hjqxw0000gq/T/tmp7zjtbv7u/flux-system-ww-gitops-values.yaml --registry-config /dev/null --repository-cache /var/folders/tj/25qdsj_n1bqfr1bwvj9hjqxw0000gq/T/tmplbwf5vh5 --repository-config /var/folders/tj/25qdsj_n1bqfr1bwvj9hjqxw0000gq/T/tmp7zjtbv7u/repository-config.yaml' failed with return code 1
Error: chart "weave-gitops" matching  not found in flux-system-ww-gitops index. (try 'helm repo update'): no chart name found

I don't know how to debug this further since flux-local seems to clean up my temp dir on the error.

I believe this is now fixed in #190 and 1.2.0. Apologies i missed this issue when you filed it.  Feel free to re-open if there are any additional issues.


Add disk/percent_used and memory/percent_used

Add percentage of disk and memory usage based on the values in disk/bytes_used and memory/bytes_used .
Includes stackdriver configuration with "custom.googleapis.com" as it is not possible to add metrics to "compute.googleapis.com".

@kasbert Please sign the CLA and squash and rebase the PR.


Add ci job for markdown linting

Is your feature request related to a problem? Please describe.
Yes, we need to provide some documentation for the repo (https://github.com/eclipse-tractusx/eclipse-tractusx.github.io). In this repo they are already using a CI job which lints all their markdown files and it was a huge task to fix all our markdown files manually.
Describe the solution you'd like
To always have proper formatted markdown files, it would be great to have a CI job which checks all added or modified markdown files of a PR.
Additional context
The repo https://github.com/eclipse-tractusx/eclipse-tractusx.github.io uses at the moment the npm package markdownlint-cli2 for linting the markdown files. The author of the npm package provides also a GitHub Action which could be used: https://github.com/marketplace/actions/markdownlint-cli2-action

ideally we can incorporate the linting into the gradle build, so that it runs as part of eg. the check task


Siad has exited unexpectedly. Please submit a bug report including the error log here.

Sia Daemon v1.3.2
Git Revision 72938f5
Loading...
(0/6) Loading siad...
(1/6) Loading gateway...
(2/6) Loading consensus...
(3/6) Loading transaction pool...
(4/6) Loading wallet...
(5/6) Loading host...
(6/6) Loading renter...
Finished loading in 2.095626723 seconds
Wallet: scanned to height 150497...
Done!
goroutine 1 [running]:
runtime/debug.Stack(0x1045ec7, 0x0, 0xc42003b948)
/usr/local/go/src/runtime/debug/stack.go:24 +0xa7
runtime/debug.PrintStack()
/usr/local/go/src/runtime/debug/stack.go:16 +0x22
github.com/NebulousLabs/Sia/build.Critical(0xc42003bac8, 0x1, 0x1)
/home/luke/go/src/github.com/NebulousLabs/Sia/build/critical.go:16 +0x93
main.startDaemon(0x0, 0x0, 0x7fff5fbffd4c, 0xe, 0x7fff5fbffd78, 0x5, 0x7fff5fbffd67, 0x5, 0x0, 0x7fff5fbffdcd, ...)
/home/luke/go/src/github.com/NebulousLabs/Sia/cmd/siad/daemon.go:212 +0x588
main.startDaemonCmd(0xc4200a6fc0, 0xc420078550, 0x0, 0x5)
/home/luke/go/src/github.com/NebulousLabs/Sia/cmd/siad/daemon.go:236 +0x162
github.com/spf13/cobra.(*Command).execute(0xc4200a6fc0, 0xc42000e0d0, 0x5, 0x5, 0xc4200a6fc0, 0xc42000e0d0)
/home/luke/go/src/github.com/spf13/cobra/command.go:750 +0x2c1
github.com/spf13/cobra.(*Command).ExecuteC(0xc4200a6fc0, 0x16e1b17, 0x3b, 0xc420093ae0)
/home/luke/go/src/github.com/spf13/cobra/command.go:831 +0x30e
github.com/spf13/cobra.(*Command).Execute(0xc4200a6fc0, 0x1b0a200, 0x16ca346)
/home/luke/go/src/github.com/spf13/cobra/command.go:784 +0x2b
main.main()
/home/luke/go/src/github.com/NebulousLabs/Sia/cmd/siad/main.go:174 +0x790
Critical error: accept tcp <IP_ADDRESS>:9980: accept: too many open files in system
Please submit a bug report here: https://github.com/NebulousLabs/Sia/issues
Shutdown complete.

https://github.com/NebulousLabs/Sia/issues/2228#issuecomment-322032996

This bug is being tracked at NebulousLabs/Sia-UI#670
It was previously tracked at #2406
There is no sure workaround that I'm aware of but you can try the instructions linked in the issues above. My understanding is this only affects MacOS. You can also try completely reinstalling Sia, only a small subset of users report this issue


Add configurations to define a custom truststore

Purpose
Make  Amazon S3 connector accept configurations from a custom truststore when a user has provided truststore configurations.

This is fixed in https://github.com/wso2-ballerina/module-amazons3/pull/27


Removed rubyforge_project from gemspec. Because rubyforge was EOL.

Thank you very much!
On Mon, Aug 5, 2019 at 1:23 PM SHIBATA Hiroshi<EMAIL_ADDRESS>wrote:

You can view, comment on, or merge this pull request online at:
https://github.com/maik/xml-simple/pull/27
Commit Summary

Removed rubyforge_project from gemspec. Because rubyforge was EOL.

File Changes

M xml-simple.gemspec
https://github.com/maik/xml-simple/pull/27/files#diff-0 (1)

Patch Links:

https://github.com/maik/xml-simple/pull/27.patch
https://github.com/maik/xml-simple/pull/27.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/maik/xml-simple/pull/27?email_source=notifications&email_token=AAAFQT4UKGVRLGUGD4F2GFTQDAEURA5CNFSM4IJKGRLKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HDLO7RQ,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAFQT4ELUD7VGZQXBIPKYDQDAEURANCNFSM4IJKGRLA
.


Fix for Firefox CSS Issues

Fix for - TryGhost/Ghost#8337

Coverage remained the same at 73.37% when pulling f9ceb5957b9300f224891e2b6ba91292f8d68c68 on rabbihossain:fix1 into 37689059aff978246187201befb0c828ceac7825 on TryGhost:master.

Thanks @rabbihossain! ❤ FYI, we have a commit message template that we try to stick to (https://github.com/TryGhost/Ghost/wiki/Git-workflow#notes-on-writing-good-commit-messages) - I've written it whilst merging this time as the PR is pretty small but something to note if you ever feel like tackling any larger issues 😄

Thanks for merging this PR. I will use the commit message template you referred for my next PR. :)


Joint example bug

Describe the bug
Joint example bug:

Engine version: latest 0.9 or 1.0

fixed by


Fixing issue where modal backdrop doesnt show

The modal backdrop shows as 0 height which means it isn't visible. This was removed in https://github.com/twbs/bootstrap/commit/14e5fb04e9bf7c406b799b75b0427522d87a4ccb but its not obvious why (and it does break stuff).  Further discussion on this commit.

Exact duplicate of #15345.


Promote pre-production client greyed out

Hi,
I am unable to promote pre-production client to production in configmgr 1810 after rollup hotfix kb4488698 was updated.
My account was added to full administrator security role site. I've tried on the insole and on the site server console. I've also tried with site server install account and promote pre-production client is still greyed out.
Could you advise what I am missing here? Thanks.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 5c6ecf9a-a586-1f34-5c41-b41081cb5e55
Version Independent ID: e29256cd-00f0-0dc9-88ea-988425858d64
Content: Test client upgrades pre-production collection - Configuration Manager
Content Source: sccm/core/clients/manage/upgrade/test-client-upgrades.md
Product: configuration-manager
Technology: configmgr-client
GitHub Login: @aczechowski
Microsoft Alias: aaroncz

Thanks @RaidenXII for taking the time to share this with the Configuration Manager documentation team. I’m sorry that you’re having problems, and I want to make sure it gets to the right people that can help. There are a couple of options available to provide the best level of support for this:

Post on Configuration Manager forums. These are moderated by our community MVPs who are very experienced, knowledgeable, and helpful.
Use Microsoft Support to search for the issue, or open a case with professional support.
Contact your Microsoft Premier team, such as a Premier Field Engineer or Technical Account Manager.

I'm closing this issue as there's nothing actionable for docs at this time.


UWP Sample: The initial screen is too wide

Describe the bug
When you run the UWP sample for the first time, the initial screen is too large.  The window is about three times wider than the list element.

Fixed by #335


Add TextTrimming

What does the pull request do?
This adds text trimming capabilities to FormattedText and therefore makes it possible to define TextTrimming for a TextBlock.
What is the current behavior?
Not supported.
What is the updated/expected behavior with this PR?
TextTrimming support for FormattedText
How was the solution implemented (if it's not obvious)?
CreateFormattedTextImpl has an additional parameter of type TextTrimming and therefore each platform needs to handle that additional parameter. Currently Direct2D1 is finished and Skia is missing the implementation.
Checklist

[ ] Added unit tests (if possible)?
[x] Added XML documentation to any related classes?
[ ] Consider submitting a PR to https://github.com/AvaloniaUI/Avaloniaui.net with user documentation

Fixed issues
#1897
#2452
Depends on
#1950

Merged into Skia text layout PR


Sigill crash in RPI 2 with allsky

I am trying to get this running on my Raspberry PI 2 board and I am trying to get it connect to my ASI120MC USB 2.0 camera.
However, following the instruction here, capture binary crashed with sigill and I realized that the Makefile is
using -march=armv7 and my board is armv61. Once I removed it and recompiled capture, it started up fine however, the libAsiCamera2.so is probably also compiled with armv7 and is crashing with SIGILL.
Any chance I can get the libASICamera2.so build for armv6? Thanks!
==========
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[New Thread 0xb01ac200 (LWP 1604)]

*** Allsky Camera Software v0.2 | 2017 ***

Capture images of the sky with a Raspberry Pi and an ASI Camera
Add -h or -help for available options
Author: Thomas Jacquin -<EMAIL_ADDRESS>Contributors:
-Knut Olav Klo
-Daniel Johnsen
-Yang and Sam from ZWO
-Robert Wagner
Thread 1 "capture" received signal SIGILL, Illegal instruction.
0xb62c73ac in ASIGetNumOfConnectedCameras ()
from /usr/local/lib/libASICamera2.so
(gdb) Quit

Hi,
Can you give me the content of this command?
cat /proc/cpuinfo
That will help me find what versions of the Pi are compatible.

I have updated the Makefile and included armv6 libraries. Can you let me know if it compiles properly?
Thanks

Hi Thomas, Thank you for your response
Here is the CPU info. I will update the makefile (I did change it and compile it already and the capture program itself works ok now - Earlier, the capture program itself hit sigill. However, now the probelm is that the shared library for the camera has the same problem . Do you also compile that library?)
pi@allsky:~/allsky $ cat /proc/cpuinfo
processor	: 0
model name	: ARMv6-compatible processor rev 7 (v6l)
BogoMIPS	: 697.95
Features	: half thumb fastmult vfp edsp java tls
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xb76
CPU revision	: 7
Hardware	: BCM2835
Revision	: 000e
Serial		:<PHONE_NUMBER>ff0400

I just noticed that you have added new libraries. I Will build and update later today after work! Thank you

I tried the new Makefile but it fails with the cross compiler not being available
pi@allsky:~/allsky $ head Makefile
platform = armv6
#INCLIB = /usr/local/include
#LDLIB = /usr/local/lib
OPENCV = $(shell pkg-config --cflags opencv) $(shell pkg-config --libs opencv)
USB =  -I libusb/ -L libusb/
LIBSPATH = -L../lib/$(platform) -I../include
DEFS = -D_LIN -D_DEBUG
CFLAGS = -g  -I $(INCLIB) -L $(LDLIB) $(DEFS) $(COMMON) $(LIBSPATH)  -lpthread  $(USB) -DGLIBC_20
pi@allsky:~/allsky $ make
arm-bcm2708hardfp-linux-gnueabi-g++  capture.cpp -o capture -g  -I  -L  -D_LIN -D_DEBUG   -L../lib/armv6 -I../include  -lpthread  -I libusb/ -L libusb/   -DGLIBC_20 -march=armv6 -lrt -I/usr/include/opencv /usr/lib/arm-linux-gnueabihf/libopencv_calib3d.so -lopencv_calib3d /usr/lib/arm-linux-gnueabihf/libopencv_contrib.so -lopencv_contrib /usr/lib/arm-linux-gnueabihf/libopencv_core.so -lopencv_core /usr/lib/arm-linux-gnueabihf/libopencv_features2d.so -lopencv_features2d /usr/lib/arm-linux-gnueabihf/libopencv_flann.so -lopencv_flann /usr/lib/arm-linux-gnueabihf/libopencv_gpu.so -lopencv_gpu /usr/lib/arm-linux-gnueabihf/libopencv_highgui.so -lopencv_highgui /usr/lib/arm-linux-gnueabihf/libopencv_imgproc.so -lopencv_imgproc /usr/lib/arm-linux-gnueabihf/libopencv_legacy.so -lopencv_legacy /usr/lib/arm-linux-gnueabihf/libopencv_ml.so -lopencv_ml /usr/lib/arm-linux-gnueabihf/libopencv_objdetect.so -lopencv_objdetect /usr/lib/arm-linux-gnueabihf/libopencv_ocl.so -lopencv_ocl /usr/lib/arm-linux-gnueabihf/libopencv_photo.so -lopencv_photo /usr/lib/arm-linux-gnueabihf/libopencv_stitching.so -lopencv_stitching /usr/lib/arm-linux-gnueabihf/libopencv_superres.so -lopencv_superres /usr/lib/arm-linux-gnueabihf/libopencv_ts.so -lopencv_ts /usr/lib/arm-linux-gnueabihf/libopencv_video.so -lopencv_video /usr/lib/arm-linux-gnueabihf/libopencv_videostab.so -lopencv_videostab -lASICamera2
make: arm-bcm2708hardfp-linux-gnueabi-g++: Command not found
Makefile:28: recipe for target 'capture' failed
make: *** [capture] Error 127

FYI: The install script has to be changed to copy the libASICamera2 libraries from the arvm6/armv7 subfolder as well. I noticed that with the latest pull, the shared libraries are soft links to libASICamera2.so.0.4.0929 however, that library itself is not included.
pi@allsky:~/allsky $ ls -lR lib
lib:
total 8
drwxr-xr-x 2 pi pi 4096 Nov 28 13:49 armv6
drwxr-xr-x 2 pi pi 4096 Nov 28 13:49 armv7
lib/armv6:
total 1168
-rwxr-xr-x 1 pi pi 1194600 Nov 28 13:49 libASICamera2.a
lrwxrwxrwx 1 pi pi      25 Nov 28 13:49 libASICamera2.so -> libASICamera2.so.0.4.0929
lib/armv7:
total 1036
-rwxr-xr-x 1 pi pi 1057600 Nov 28 13:49 libASICamera2.a
lrwxrwxrwx 1 pi pi      25 Nov 28 13:49 libASICamera2.so -> libASICamera2.so.0.4.0929

Quick update:
Instead of the shared library (which is a softlink), I switched to the included static library for armv6 and compiled it and it loads up (Awsome!)
I hacked up the Makefile

In the Armv6 , the make file tries to look for arm-bcm2708hardfp-linux-gnueabi-g++ and this is not available (only arm-linux-gnueabihf-g++ is available). So I switch to using arm-linux-gnueabihf-g++

Instead of shared library -lASICamera2.so, I switch to static compile

capture:capture.cpp
$(CC)  capture.cpp -o capture $(CFLAGS) $(OPENCV) lib/armv6/libASICamera2.a -lusb-1.0
Once I compiled it, the app started with no crash and started to take images with the ASI120MC USB 2.0 camera  (though it was blank but that could be my settings that I need to check now)

Thanks for the debugging on your side.
I have updated the README and re-added the shared libraries.
I compiled using the armv6 and the armv7 flag without issues on my armv7-compatible Pi2.
I will close the issue for now. I'll re-open it if you come across any issues

Thank you so much! This is such an useful program. I got it working with my ASI224MC . I probably need to update firmware on my ASI120MC (it only gives black frames regardless of exposure).


Theme: Interactive Terminal

Hi,
Firstly great work on this theme!
Secondly apologies if this has already been answered somewhere (I looked but couldn't find anything).

We have been using Shellinabox to provide a web based shell, but now with the implementation of your Authentic theme to Webmin, we have a shell there too, so am considering dropping Shellinabox altogether.
However, I notice that the Webmin shell is not picking up the default colorization that I currently get via both an SSH session, or via Shellinabox (see screens below). Also the text is quite small and not that easy on the eye (at least mine anyway).
Is there any way I can adjust that. Primarily I would like to enable colorization of the shell, but it would also be nice to increase the font size a little.

SSH session

Shellinabox

Webmin Authentic shell

FWIW it looks like the TERM variable isn't being set. I tried manually setting it within a session, but even if I export it, it doesn't seem to stick?!?

imho this is not a real shell, each command is executed in seperatly.

@gnadelwartz ok thanks for that. I have zero perl experience, but I did have a dig in the shell user interface index.cgi file but couldn't really see what is going on there...
Regardless, I'd still imagine that it must be possible to set/update environment variables?! Even if the renderer didn't know what to do with them (so we'd likely get a heap of escape codes instead of colors).
This isn't a showstopper for me, but it would be nice if I could adjust the font and would be super great if it could have colorized output!

Ok, now I'm digging a bit deeper, I'm not sure whether this "pseudo-terminal" shell will be good enough... As it doesn't support interactive commands, I'm looking at other ways to achieve my ends.
I see that there is a shellinabox module (noted at the bottom of this doc page and here is it's directory in the source). I wonder if there is a way that I could leverage that to provide the Authentic theme shell?
I really like everything about the Webmin authentic theme shell, expect the fact that it's not a proper shell. I understand that Webmin is cross platform, but I would imagine that it's most commonly used with Linux (users used to a GUI, managing their Linux servers) so having a "proper" shell would be a huge advantage IMO...

Oh, just noticed that the shellinabox module appears to be abandoned (last commit 2012!). There is an ajaxterm module too, but that is also more-or-less abandoned...
 I think I might just stick with Shellinabox for now...

I had a quick look at the code and unfortunately, I don't see what I would need to do to import an updated version of Shellinabox into Webmin, but it appears that it should be possible. And if that can be done then, I'm pretty sure that we could then replace the current pseudo-shell accessible within Authentic theme with Shellinabox.
But unfortunately, with my lack of perl knowledge and a big todo list, I'm going to need to put this aside for now...

@swelljoe @qooob didn't found the issue where we discussed replacing current terminal with a modern and real interactive solution, but we should think about a new try after realease.

Jeremy, hi.
You can easily increase the font of the whole Terminal just by adding to theme's extensions, this CSS code:
.-shell-port- {
	zoom: 1.2
}

Note: After saving changes, for now, you would need to refresh the browser's page to get the effect.
What's for interactive shell. We're all looking forward to have it.
I will think more on how it could be done. Fedora Cockpit has it for instance. Shellinabox has unofficial fork. The problem is to make it work on all Linux distros. We could make a build and create AppImage to make sure that it just runs without hassle. After all, I would need to make a port to the UI.
I will mark this issue as an enhancement and will look forward for enrolling it. It will be for sure after the new mail is released, into more or the less stable condition, which estimated to happen around summer 2018.
I absolutely agree, that having proper interactive console is a huge win. I'm making it a second priority after the mail.

I will look into Gate One as possible choice.

this would be ny initail suggestion also, phyton and javascript should be portable

I managed to install Wetty in no time.
Requires only NodeJS.

nice, but this adds a new dependency :-/ nodejs may not installed everywhere...

We could try to make AppImage, just export all of the dependencies into single, self-contenting package.
We could surely keep current implementation as a fall-back.

Yeah, I'd rather not depend on node.js in Webmin. Can the server-side part of this be re-implemented in Perl?

Reimplemented? Technically but not practically. It's very resourceful/time consuming. Besides, there is implementation in Perl (Shellinabox).
I haven't looked very closely yet to make a judgement.
Why we just can't ship AppImage - single, executive file that would contain all dependencies in one. I'm not saying it's the best way, but it looks for now as the fastest solution.

I would also prefer a perl or phyton inplementation (as we currently has).
Is you appimage sulotion is portable or does it depend on OS and CPU architecture?

Requires only an entire new runtime, eh? ;-)
Requiring Node is too much, I think, as it is not commonly installed and is very, very, large. But, then again, the alternatives aren't great either. Python can be expected to be available everywhere, already, but I dunno if there's a WebSockets based back end available that'd work with one of these modern JS terminal implementations. There's one in Go called gotty, but it'd only work on Linux systems (the server-side, obviously the client-side is JS and would work anywhere).
I dunno. We pretty much have to spin up a new back-end webserver, no matter what, as miniserv.pl doesn't support websockets, yet. Python is more readily available than Node (for now), but I don't know of good options for that. I haven't looked at Shell In a Box, I think it predates websockets, though, so I doubt it's the modern approach we'd want.
There is a WebSockets implementation for Perl in Mojo (as well as several compiled ones, but I think Mojo is good as it has fewer dependencies than most), but someone would need to implement the shell backend (I don't know what that entails...we'd basically be porting the backend in Wetty or Gotty to Perl). I'll have a look at those backends and see how much code we're talking about...I think the heavy lifting is on the front, so maybe it wouldn't be so awful to port it to Perl.

Maybe this: https://github.com/Prajithp/mojo-terminal

As noted above  Gate One at least state:

Gate One works with Python 2.6+, Python 3, and even pypy!
The daemon that acts as the web server for Gate One is small and light enough to be included in embedded devices.

https://github.com/liftoff/GateOne/

Maybe this: https://github.com/Prajithp/mojo-terminal

wow. seems really small (execpt of require mjojo)

Great work guys, pumped about all the activity... :smile:
Gate One looks good.
I agree depending on Nodejs is not desirable!
Out of curiosity, why is Shellinabox out of contention? IMO it works quite well. Although it is a little flaky on mobile devices...

mojo-terminal looks very good, if it is in a functional state. It's very light, only has a few dependencies (still checking to see if they are pure-Perl or if there's some compiled bits), and it uses the same frontend as all of the others we're talking about (xterm.js), so it'd be something we could sort of pin to whatever version is current and just perform minor updates based on what upstream does. I think this might be a winner.
A couple of XS dependencies (IO::Tty, though we already use IO::Pty, which is a similar size/complexity dependency, so this is probably not a dealbreaker). I'm looking at the dependencies now to see which ones are already in CentOS/Debian repos, and figuring out if we'd need to package any extra modules. Mojo is not in the CentOS core repositories, but I think it is in EPEL. And, it's pure-Perl and only a couple thousand lines of code, so we could even bundle the damned thing as part of Webmin.
Mojolicious is really an amazing bit of code. It does so much with so little code. I'm in awe of it every time I look at stuff implemented with it.

Out of curiosity, why is Shellinabox out of contention? IMO it works quite well. Although it is a little flaky on mobile devices..

Not out of scope but if we implement a new solution it has to fit some requirements:
modern(e.g. websockets) , futureproof, portable (perl, phyton)...
BTW:  cpan Mojolicious works without a charm on my embedded NAS

I don't know that Shellinabox is out of contention...I just know it's really quite old, and I doubt it is a modern implementation. With Websockets, it is now possible to have a very efficient communication between the browser and the server; but it's a relatively recent thing. I think Shellinabox pre-dates it. If it does, the implementation would be poll-based, and also very large compared to these WebSockets-based implementations. The smaller it is the better, because we can probably maintain a few hundred lines of code if it goes abandoned in the future, but we can't realistically maintain or understand or audit thousands of lines of code (and security is a big issue with anything we ship in Webmin).
So...if we can find an implementation of this that is:

Small. A few hundred lines of code, hopefully.
Doesn't require a new runtime: Limited to Perl or Python, probably.
Works with a well-maintained frontend. I think this is just xterm.js, as I don't know of any other frontends that are widely used.
Has minimal dependencies, preferably no or few binary packages. I suspect any Perl thing will require at least an XS module or two for the IO, but that's probably OK.

Sounds great. Thanks for the explanation, that makes tons of sense. And yes, Shellinabox is old. It died but has been (somewhat) resurrected, but AFAIK no major changes to the codebase (just some updates and bugfixes).
It looks like you guys are all over it.
In the meantime, if I come across anything that fits the bill, I will certainly let you know.

So, for dependencies:

CentOS core has perl-IO-Tty
We already use perl-IO-Pty (though I dunno where we get it from, as it's not in core, maybe it's in EPEL or we've got a build of it somewhere in our repos).
Mojo isn't in either core or EPEL, but the bits we need are pure-Perl, as far as I know, and only a couple thousand lines of code, so we could bundle the damned thing with Webmin (which is several hundred thousand lines of code, so not a big deal).

I think that's realistic. So, I'll need to try it out to make sure it's actually in a usable state...sometimes projects get kinda half finished and the maintainer gets bored and moves on before it's solid.
There will need to be code to spin up the sockets server on demand. I don't know how authentication is handled in the AJAXTerm module (which I think is the closest comparable Webmin module), maybe you actually have to login again...I don't remember. But, we'll have to make sure we get that bit right. Ideally, it wouldn't require logging in again, so I guess we'd need to set a JSON Web Token to authenticate the current session, maybe.
@qooob what are you doing about authentication when you use wetty in this context? Is it requiring a new login or are you setting a token?

Let me know if anything needs testing and/or you want any further feedback.

Mojo isn't in either core or EPEL, but the bits we need are pure-Perl

as long CPAN is working it can simply installed

perl-IO-Tty ... perl-IO-Pty

I see also no problem with this, may be we can unify it to one of them ...

Great work guys, pumped about all the activity...

as you can imagine, we are not really statisfied with current terminal :-)

I don't like to rely on CPAN for Perl modules in anything we ship in Webmin core, or in Virtualmin. Jamie is more relaxed about this than I am, but if we can't include it as a dependency in the Webmin package, I wouldn't want to make it part of core Webmin (this means it needs to be available in the core OS repos, which IO::Tty is, and I see it includes IO-Pty).
So, Mojo is the only unresolved dep, I think. One other XS module needed is Encode, but it's also in the core CentOS repos (and I just assume that anything CentOS has, Debian/Ubuntu will have because they have a lot more Perl packages). So...the new terminal module probably just needs to embed Mojo in a directory and add it to the library path when it spins up the server.
We may still want to make this a non-core module that gets installed as part of Virtualmin and Cloudmin. If there are other XS (binary) dependencies hiding in here that I haven't found yet, and they aren't available in the core OS repos so we can depend on them in the Webmin package, I'd want to see this as an external module. But, it looks like that won't be necessary...we can probably ship all the non-core bits we need in the Webmin package.
And, yeah, the current popup terminal in Authentic is awesome, but it's not really a terminal...it's a command shell that looks really cool. It's never been intended to replace an ssh session, but the tech exists to replace ssh sessions (or put them on the web), we just don't have it in Webmin yet.

And, yeah, the current popup terminal in Authentic is awesome, but it's not really a terminal...it's a command shell that looks really cool. It's never been intended to replace an ssh session, but the tech exists to replace ssh sessions (or put them on the web), we just don't have it in Webmin yet.

Yeah it tricked me initially! It wasn't until I followed the hint from @gnadelwartz and I dug in a little that I realised what was going on. Even as it is, It's certainly handy (and looks nice) but I was looking to replace our current (standalone) Shellinabox implementation. I don't need a perfect SSH replacement, but I do ideally want a Sheelinabox replacement! :smile:
Despite Shellinabox being old (and a little bit clunky) it works quite well. But I'd much rather consolidate all the additional remote access stuff within Webmin (so no need for an additional service and port open). If you guys find and can implement something even better than Shellinabox, I'd be super keen!
Oh, and as requested by @gnadelwartz :smile: :

I tend to use mojo-terminal as well. I will have to take a closer look first though. I tend to use Perl as back-end as well for better overall compatibility.

@qooob what are you doing about authentication when you use wetty in this context? Is it requiring a new login or are you setting a token?

Wetty runs /bin/login, so no, plain authentication with login/password. It supports other methods, supposedly even tokens and other but I dind't try it.

I started tinkering with mojo-terminal, and it is functional, however, it has no authentication...it doesn't even ask for a login, it just runs as the user that started the service.
This means it needs an authentication layer implemented at the Mojo level, and we need to be able to set a session cookie in a Mojolicious compatible form within Webmin for each user with an active terminal.
We also need to be able to spin it up when the user asks for it and kill it when the user logs out (this will mean it is slower than the current popup terminal on first launch, but not by much...on my laptop, mojo-terminal is able to answer requests in less than a second). But, each process requires about 200MB/37MB (virt/res), so we can't just spin it up on every login, as any system with more than a few active users would end up pretty big pretty fast. I think the spin up/down code mostly already exists in the AJAXTerm module, so I'll look at that to see if I can steal it. But, authentication will be harder, I think. Webmin's session cookies aren't the same as Mojo's (though maybe I can convince Jamie to implement JWT auth in Webmin, which would be re-usable against Mojo). I'm a bit iffy on how authentication across ports can work.
Mojo can also listen on a UNIX socket (a local file), but I don't think Webmin can proxy WebSockets so that probably won't work, anyway...though it'd solve the authentication problem, if it could, since we could create a file for each user owned by the user and Webmin could just talk to it as the logged in user, (or root), and even local users wouldn't be able to abuse that.

Sounds good. I'm a little baffled, is there really that much resources needed?
It would be great to have it replacing old AJAXTerm in the end.

I mean, each process is 40MB resident (200MB virt). That's not "much" by many standards...but, on small machines that are already packed to the gills (a 1GB machine running a Virtualmin default setup, including clamd, there is no room to spare), it could put the server into swap hell with just a few users spinning of concurrent shells. That's more than spawning Command Shells on demand, by a lot.
But, yes, it's probably smaller than AJAXTerm. But, we don't put AJAXTerm into a spot where hotkey can pop it up for any logged in user.
It's just a matter of managing expectations, I think. This is going to spin up a process that's as big as, or potentially bigger than, Webmin itself, for every user that spins up a terminal. That isn't intuitive; who would expect a shell to be as big as the GUI? Certainly much of it will be shareable, as it's all Perl (this is another good reason to use something in Perl...we know the shared system libraries are gonna be mostly the same for Webmin and the other Perl processes).
Anyway, it's fine. It's fast enough, I think, and small enough. I was just sort of notating what I'd found in looking at it, so we know what we're dealing with. I'll fork it and add authentication tomorrow, and then from there, maybe get Jamie to sort out the part where Webmin auto-authenticates (I don't understand Webmin's session handling or how it makes authenticated calls to things like AWS, which is kinda what'll be happening here).

@swelljoe any progress on this topic?

Since there have been no follow up posts ...
Regarding colourisation of output from commands ...
I have a Custom Command which looks like this ..
 /etc/ansible/inventory/gce.py --list |  python -m json.tool | pygmentize -l json | aha
The custom command must be set to HTML output for this to work.   Also in Ubuntu aha must be installed and python pygmentize module.
gce.py is a standard script used in Google Cloud API.
...
Returning to exploring a standard shell module, I have looked at wetty (which requires node.js) but I am now focussing on building butterfly into a custom module.  My aim is to build a module to run Ansible scripts from within Webmin framework. i.e. using webmin as the controller for running Ansible scripts on both the local server and satellite servers.
butterfly with SSH

I use webmin mostly for the file manager to edit files but being able to use it also for the command line would be a really nice thing. Are there any final conclusions of what software to use and when you can implement it?
@swelljoe said in a referenced issue that some heavy lifting is involved for both back and frontend.

@rostovtsev and @swelljoe
Any news on this?

Nothing interesting. I have been tinkering with Mojo Terminal, and kinda have a vague notion of how we can implement authentication safely, but it's still theoretical, and my knowledge of Mojolicious is pretty weak. I'd like to be able to ship it in time for Virtualmin 7, but I'm not super confident I'll be able to sort it out by then with everything else I've got going on.

Hey @swelljoe, I was very happy about the new monitor on the dashboard, how about the interactive Terminal? Any news?
And thank you for all the work already done! :)

Thank @rostovtsev for the new realtime monitoring in the dashboard (and it is very cool!), as it's all his doing.
Nothing new. I had some personal stuff that kept me away from doing much work on Virtualmin, and took a now job at the beginning of 2019 that also took (and continues to take) a lot of my time. With what time I do have (weekends and holidays, mostly), I've been focused on catching up on OS support (Debian 10 and CentOS 8), and fixing some major problems with the website (replaced forums during Christmas holiday, and will hopefully have commerce and issue tracker replaced over the next couple of weeks).

Thank @rostovtsev for the new realtime monitoring in the dashboard (and it is very cool!), as it's all his doing.

Thank you for your kind words, Joe! :smile_cat:

.. and will hopefully have commerce and issue tracker replaced over the next couple of weeks.

Looking forward to it!

 Hope you guys are all fine! :)

wetty has been mentioned in several tickets about this (including the Ajaxterm one I just linked to this ticket), it is not an option because it requires nodejs >=14, which is in almost none of the operating systems we support. Ubuntu 20.04 has NodeJS 10. 22.04 has 12. CentOS 7 has some version from before the reversioned (some some .0.10 or whatever the heck). Requiring 14 is absurd, and a complete non-starter. We can't expect users to enable extra repos and install a whole huge stack of extra packages just to get a danged terminal.
Webmin needs to be installable and usable using just packages the OS standard repositories.

Terminado is apparently a spiritual successor to AJAXTerm, though it uses WebSockets and is actively maintained. It may be a better choice than the Mojo option mentioned earlier, since it is maintained by a large/active project (Jupyter). https://github.com/jupyter/terminado

I think we could use Wetty as a Docker container, cause it's very easy to deploy:
docker pull wettyoss/wetty
docker run -d --name virtualmin-wetty-localhost --rm -p 3000:3000 wettyoss/wetty --ssh-host=<IP_ADDRESS>

Practically all is done.
Although, we need to use a proxy to add https to Wetty by simply creating Apache config, like virtualmin-wetty-localhost.conf with the following content:
RewriteCond %{REQUEST_URI}  ^/wetty/socket.io [NC]
RewriteCond %{QUERY_STRING} transport=websocket [NC]
RewriteRule /wetty/socket.io/(.*) ws://<IP_ADDRESS>:3000/wetty/socket.io/$1 [P,L]

<LocationMatch ^/wetty(.*)>
  DirectorySlash On
  Require all granted
  ProxyPassMatch http://<IP_ADDRESS>:3000
  ProxyPassReverse /wetty/
</LocationMatch>

This is also very easy to support and update, and moreover it fits our future plans in adding full Docker support.

but as Joe mentiones with node, docker as prerequisite for webmin may not availible on  all supported systems, especially on the embedded ones I care a little about.
BTW: How are you doing?

docker as prerequisite for webmin may not availible on all supported systems, especially on the embedded ones I care a little about.

Well, Docker is available on all distros we support.

BTW: How are you doing?

Thanks, doing good!

I suggest we do the following. I will create a new module with the name SSH Connect. This module will automatically install Docker and setup Wetty container, familiar way we setup OpenDKIM in Virtualmin.
It will automatically setup a connection for the host default IP (to local SSH where Webmin is installed). Also it will be possible to add any other additional/external SSH servers and switch between them. Authentication won't be handled (at least for now) and a user would need to enter a login and password.
It will at last adds proper interactive console support inside of Webmin. I will probably also be able to replace the theme dropdown command shell with this new local SSH connect, if access to this module will be allowed.
Examples:

https://user-images.githubusercontent.com/4426533/193034266-55ef5622-6dd3-4c59-8aa4-f3bb0be3742e.mp4

Whoa, that seems like a LOT of dependencies if we have to do a full Docker install! Is there something else we can install that's simpler or can be packaged with the module?

Egads. I am alarmed.

Do you have suggestions? What would be another competitive to Wetty solution?

I posted one above. Terminado requires only a handful of Python modules (and I think the only binary module of them is available in OS repos).

A docker solution means it can't possibly run on embedded devices, as gnadelwartz mentioned. And, it's crazy heavy to spin up Docker+Node+wetty for every terminal session.

Terminado can probably be almost entirely bundled as pure Python...with I think only one binary dependency on the tornado library (I assume tornado is binary, as it's the async library and web framework..but, since it's available in OS repos, it's entirely fine, we can depend on it in Virtualmin installer, and Webmin can offer to install it or just suggest installing python3-tornado when users try to use the terminal if it's not installed).

And...Terminado is actively maintained by a big community (Jupyter is huge, and has corporate backing from MS, Google, all the AI companies, etc.). I can't see a good argument for wetty over Terminado.

Terminado is actively maintained by a big community (Jupyter is huge, and has corporate backing from MS, Google, all the AI companies, etc.). I can't see a good argument for wetty over Terminado.

I haven't checked Terminado yet.

Whoa, that seems like a LOT of dependencies if we have to do a full Docker install!

Yes, somewhat. Podman install takes about 65 MiB. Wetty container size ~400 MiB.

And, it's crazy heavy to spin up Docker+Node+wetty for every terminal session.

Well, yeah around 50 MiB of RAM per container.

I can't see a good argument for wetty over Terminado.

Wetty container needs no support and easy to upgrade.

A docker solution means it can't possibly run on embedded devices, as gnadelwartz mentioned.

Are there many systems like that to worry about it?

I don't disagree that using Wetty container is sub-optimal. First of all, it was just a suggestion to discuss. I haven't implemented anything yet.

Sorry I never did get back to looking at shellinabox... FWIW it is still packaged in Debian (not sure about any other OS). It's installed size is 507kb and has minimal dependencies.
As I noted previously, there already is an (old and seemingly unmaintained) shellinabox Webmin module. Perl and javascript are not technologies that I'm particularly comfortable with, but if that's a workable option, that's the path I'm inclined to investigate myself unless there are significantly better options.
Would there be any technical limitations/considerations that any of you guys could think of in trying to port the old shellinabox module to modern Webmin/Authentic theme? ANy other advice and/or guidance? (Ideally aimed at a Perl/Javascript newb! :rofl: ).
As for this general discussion, Node dependency is undesirable IMO (no issue with javascript per se - I'd just rather avoid having to install 60MB+ of additional deps if I can avoid it). OTOH, I get that it's popular these days and quite powerful, so may well be a requirement. Docker dependency would almost certainly be a deal breaker for me though, especially if the required container is 400MB!

Thanks, Jeremy. We will look into a lighter and better implementation for the terminal support in Webmin.

I can't think of a good reason to use shellinabox for this. An existing module (that doesn't work the way we need it to, as shellinabox requires the user to login again), doesn't really help speed things along. It's not much of a "popup shell" if you have to login every time it pops up.
The problems we need to solve are mostly the same, regardless of the backend (as long as its a backend that starts as a user and we can bind it to a socket and proxy to it through Webmin). So, if we're going to do the work, I'd rather it be against a project that is actively maintained and easily installable across all supported distros.
To be clear about the problems we need to solve to have a really nice popup shell that is actually a shell:

Webmin's miniserv.pl ideally would be able to proxy WebSockets. Jamie's going to look into this, and I have high confidence he can implement it...but, I don't know how long it will take. The alternative is to put each new session on a new port and put it in an iframe, and handle authentication some other way (probably setting a JWT or something that the shell backend can read). The latter requires friendly firewalls all along the way, and some other things that are tricky to make reliable. Proxying is the only good solution to this problem.
Backend needs to be able to bind to a UNIX file socket (rather than listening on a port, as even localhost is not safe in a multitenant system). Terminado can do this. Any Docker thing can do this (but I consider Docker and Wetty a non-starter for other reasons). Or, alternatively, if we can't proxy through Webmin, the backend needs to authenticate via something like a JWT or shared session token or something, so the user doesn't have to login again, but also any rando connecting to that port can't just start typing away as the user that started the process.

The first one is a hard problem. It requires code. Probably quite a bit of it. And, probably Jamie is the lone person really capable of implementing it in a reasonable time, since he knows the miniserv.pl code very well (having written it).
The second one is a probably not hard problem. Terminado can probably bind to a UNIX socket with minimal changes (Ilia has a ticket open discussing it with the Terminado folks, and it seems easy enough). Little to no code. If we can't proxy through Webmin, the second option may be harder, though I think implementing authentication is probably a much less hard problem than proxying WebSockets in miniserv.
If WebSockets proxying in Webmin will take months (which it might, I don't know, Jamie hasn't started, AFAIK), then it may be worth implementing the alternative of putting the backend on a new port per session, and handling authentication another way.
Again, the backend in this scenario is almost irrelevant to how long it will take. Might as well use a modern WebSockets-enabled option that is actively maintained. I think that leaves Terminado (very maintained), Wetty (very maintained), maybe GoTTY (seems unmaintained-ish), maybe Mojo Terminal (only because it's in Perl and we could maintain it ourselves pretty easily, if it came to that, but seems only lightly maintained).
ShellInABox has a different set of problems to solve, but probably not much less work. Login is one to solve. Proxying to it via Webmin is maybe already possible, since I don't see evidence it uses WebSockets and instead uses polling, though I doubt that old module does it that way.
Note that polling makes for a much worse user experience, especially on slow links, which is why I'd rather we use something modern with WebSockets.
It continues to be a serious usability problem that people think the popup shell is a real shell. e.g. from yesterday: https://askubuntu.com/questions/1433217/sh-1-y-not-found
In the short term, we need to make it much more clear that this is not ssh, it's not a real terminal. We need a sensible error message when a user tries to run an interactive command or anything else that the popup shell is going to barf nonsensically on. The current behavior just feels really bad. If it stays this way, I tend to want to hide it behind a config option (as much as I hate adding config options, having users think we ship shitty broken software is way worse).

From glancing at the websockets docs, it looks like a proxy should be pretty easy to implement .. less than a week's worth of work.

FYI, initial support for websockets proxying in Webmin is here : https://github.com/webmin/webmin/commit/273100ec6ebae3234ecf4765e9380789db4aa81e

That's remarkably faster than I expected, and it's also remarkably less code than I expected it would need!

I haven't actually verified that it works for real yet, so let's not get too excited :-)

Ok the code is verified working now, and I've updated Cloudmin's VNC console support to proxy via websockets.
Next step is to find a good server-side websockets shell, and a javascript terminal emulator that can talk to it.

Can I assume your implementation can talk to a UNIX socket backend? I don't know if Ilia figured out how to make Terminado work on a UNIX file socket, but if so, that's probably the best option for bundling with Webmin (Python, few dependencies, all of which are available in OS repos). In the short-term, if either you haven't implemented proxying to a local file socket or Ilia hasn't figured out how to make Terminado run on one, experimenting with a network port is also probably a reasonable next step, just to prove the proxying is covering everything it needs to for Terminado to work.

Alrighty then I will start working on a new Terminal module.

I've added unix socket support, but not tested it yet ..
@iliajie I can do the module.The hard part will be figuring out how to package Terminado as part of it..

The hard part will be figuring out how to package Terminado as part of it..

I am not sure that it's the hardest part. I think I will do the module as well, and you can add fixes if needed. However, the hardest part (as the last time I was trying it) is to make Terminado work with unix sockets (works with TCP). There is no documentation on this. I would have to look deer into Tornado documentation or just ask for a help on this from people working on the project.
Although, I made it partially work as described here https://github.com/jupyter/terminado/issues/192. Perhaps the problem itself was in a proxy. There was no obvious reason for it not to work. I didn't dig that deep in it yet but I am planning to start working on it tomorrow.

Also, how do you see this new module working? I see it as a replacement for Text Login doing practically the same + having an active session (where no username and password) for the current user. When the module link is clicked in the menu, it will open a new Terminal window with authenticated session for the current Unix user. Sudo-capable Webmin users will use Unix root user. I presume, that we will need a check on the regular user's shell.
Later, I will incorporate this into the theme drop-down shell, if this new module is available for a user.
By the way, could you fix Command Shell module to return a proper error message, when user calls an interactive command, like top? So the error message will say what exactly the problem is instead of saying TERM environment variable not set., which is very confusing.

Yes, that's exactly how I am thinking it would work.
Can we package Terminado as part of a new module though?

Can we package Terminado as part of a new module though?

I'll check what we can do.

Terminado itself is pure-Python (and JavaScript for the client-side), and most of its dependencies are also pure-Python. It's possible to munge the PYTHONPATH (the library path) to include the install dir. The path would need to be appended to the usual PYTHONPATH, I think, since we need the rest of the standard library and we need the binary package for tornado (the async IO library).
There is a package python3-tornado in Fedora, CentOS/Alma/Rocky, and recent Ubuntu/Debian. We probably should not add a dependency on this for Webmin. Maybe the terminal should be in its own module package, so it can have more dependencies. We may be able to get all or most of the other Python libs from the OS repos in that case, which would maybe be a nicer choice than making the module big.

I don't think a virtualenv (which is what I usually do to simplify packaging Python apps) can work for this, as building the virtualenv would bundle up the binaries, too, and those are not cross-platform.

But, we can manually build a sort of virtualenv with just the Python bits, and munge PYTHONPATH at runtime.

Also, I would discourage wasting time or effort on python 2 support. There is no future in it, and all of our support distros for Virtualmin are on Python 3 by default.

I wonder if there's an even lower-dependency option, like using xterm.js in the browser, and creating our own simple websockets server that just proxies to /bin/sh

There probably is. It's beyond something I could whip up in a weekend, though.
But...looking at Mojo::Terminal, it is remarkably little code: https://github.com/Prajithp/mojo-terminal/blob/master/lib/Terminal.pm (plus some HTML and the JS)

I'll take a look .. is Mojo::Terminal also a websockets server?

No. Mojo::Terminal is just a simple Mojo app. Mojolicious provides the WebSockets infrastructure (and which app server Mojo runs under is flexible...they all support WebSockets, though). morbo is the default dev server bundled with Mojolicious. (https://docs.mojolicious.org/morbo)
And, reading all this has me back to thinking Mojo::Terminal is the better fit for Webmin, if Jamie's idea of writing something from scratch doesn't happen. Mojolicious is quite light, and there are packages for it, too.

And, I think it's all pure-Perl. Looks like the poll implementation is, anyway, and that would usually be the spot I'd expect binary bindings. That's one of many striking things about Mojolicious. Tiny code implementing a horribly inefficient poll: https://github.com/mojolicious/mojo/blob/main/lib/Mojo/Server/Morbo/Backend/Poll.pm
But, the fact that it's horribly inefficient probably doesn't matter. I think we could bundle this tiny tiny WebSockets server with no binary deps, and, I think it'd probably be fine for running a few shells. (Then again, somebody will run a Virtualmin system with a hundred active popup shells and complain about performance at some point.)

To make it fast enough for many clients we'd have to use a WebSockets implementation that uses some kind of binary async package, but I think that's a bridge to cross another day.

Back to Terminado - I was thinking of installing python3-tornado from OS repos and bundling Terminado with Webmin.

I think Jamie's going to solve it all by writing a few dozen lines of Perl. Sometimes, NIH serves the greater good.
But, also I'm less enthusiastic about Terminado now that I see how small Mojo::Terminal is, and the fact that Mojolicious, including the morbo app server, is pure-Perl, and thus the necessary bits could be bundled completely into Webmin with no external dependencies. (Mojolicious, minus tests and examples is about 2.4MB). No external dependencies, particularly no binary external dependencies, is extremely appealing. So, if Jamie doesn't implement something (though seeing how little code it really takes, I think Jamie probably can implement something), I think Mojo::Terminal is probably the path of least resistance. And, it's so little code, it'd be easy to maintain. xterm.js is maintained by others already, and that can be upgraded without changes to the backend.

I don't know. We already have so much code to support.

Did you look at the Mojo::Terminal link above? That's not much code. Two pages. Dead simple stuff. I think I'd rather commit to maintaining that than bundling something that has an external binary dependency that may or may not be available everywhere and forever.

I haven't yet. Quick looked though -- it wants Perl 5.30 or higher. Also, it hasn't been maintained for the past year. Perhaps it's that simple, and just works.

Ah, that is problematic. Mojolicious was OK with 5.16 up until pretty recently. Now it says 5.26 (but 5.16 with some CPAN modules...). I guess I'll have to look into that deeper.

So I've made a lot of progress on this, and have gotten to a point where an interactive shell is fully working in Webmin!
In the end, the only dependencies needed were xterm.js (which we can package with the Webmin module), and the Net::WebSocket::Server perl module. There was no need for Mojo::Terminal or Terminado, because the code to convert between websockets and a shell process was trivial when Net::WebSocket::Server is installed.
There's more work needed, but it's mostly cleanup and permissions improvements at this point.
Code is at https://github.com/webmin/webmin/tree/master/xterm . Also needs the latest checked-in miniserv.pl with websockets proxy support.

Fantastic, Jamie. I will give it a try and integrate it to the UI (as a drop down terminal).

Net::WebSocket::Server has the negative that it's not available in OS repos, like Mojolicious is. While, it's good to drop Terminado as a dependency, it's not really a win to avoid a dependency on Mojolicious only to replace it with something that is much less widely available.
Mojolicious is available for all of our recent supported distros Net::WebSocket::Server is available for none, as far as I can tell. Unless it's a pure-Perl library, we're gonna have to deal with a missing binary dependency. I can't tell off-hand whether it's pure-Perl or not...

Looks like it might be pure-Perl, though? It calls itself "server with minimal dependencies", but I'm still clicking through all of its dependencies trying to figure out if any of them are binaries...

OK, I did a test install using cpanm --local-lib and I don't see any binaries in there, so I guess it is pure-Perl. Objections retracted, as long as we can reasonably bundle it in Webmin (and, the whole install dir is a very reasonable 604k, so I don't see any reason we couldn't).

Yeah I haven't checked yet if it can be packaged with the module, but if there's no binaries that would be the simple option.
Also, using a library like Net::WebSocket::Server gives us a lot more flexibility to implement our own authentication method.

That works for me too. Awesome! Let me know when I can change the code for the module (UI wise).


fix: Lambda download during worker pool recreation, remove temp file

Description of the change

Fix mkdir error: "cannot create directory ‘lambda’: File exists"
Fix unzip interactive prompt/error: replace LICENSE? [y]es, [n]o, [A]ll, [N]one, [r]ename:  NULL
Remove temporary zip file

Type of change

[x] Bug fix (non-breaking change that fixes an issue);
[ ] New feature (non-breaking change that adds functionality);
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected);
[ ] Documentation (a documentation or example fix not affecting the infrastructure managed by this module);

Checklists
Development

[ ] All necessary variables have been defined, with defaults if applicable;
[ ] The code is formatted properly;

Code review

[ ] The module version is bumped accordingly;
[ ] Spacelift tests are passing;
[ ] This pull request has a descriptive title and information useful to a reviewer. There may be a screenshot or screencast attached;
[ ] This pull request is no longer marked as "draft";
[ ] Reviewers have been assigned;
[ ] Changes have been reviewed by at least one other engineer;

@eminalemdar could you take a look at this one? I think you added the autoscaler code, so are probably best placed to review this.

@MaxymVlasov can you please rebase on main for this PR because this branch is out-of-date. and also the in order to docs check to run you should push another commit for that.

Done


Move docker images to use node v10

Description
Move docker images to use node v10
Tested
Google Cloud build is building and testing the changes.
Locally tested one file $ docker build -f dockerfiles/celotool/Dockerfile .

🙏 thanks! sorry missed this

No worries, at some point, we will have to make Google cloud build a mandatory step as well.


Add note about remote VM access

Looks good. And the VM works great. Much smoother than I imagined.


Feat: Allow users to click components (and allow components to consume these clicks to do "stuff")

Requested feature
Another plugin I use nvim-cokeline supports clicking an icon in a tab to close out the buffer. That got me wondering, what would the work effort be to allow users to click a component in lualine and allow the component to perform some "action" based on this click.
As an example, I could integrate a plugin with it where if the user clicks a component, the click would trigger a floating window to appear with information.
Motivation
There isn't any real motivation aside from "this would be cool". I can dig into how difficult it would be to do this, though I would like to get someone's approval saying they agree with the idea before pursuing it

I think it's a good idea to add supports for this . It shouldn't be too hard to add support for this . What I have in mind:

Add a new option support to basic component class (on_click ?)
It should accept a lua function and store it away during component initialization so it can be exposed later while drawing.
Use the click syntex  of statusline to wrap the component in clicker while drawing the component .

Most of the stuff can be done in lua/lualine/component.lua. What we'll have to decide is how the callback gets stored (May be a additional module that handles storing and exposing callbacks).

It looks like both the plugin I mentioned and lualine do some weirdness with string formatting to "emulate" handling mouse clicks? I am having trouble parsing it, Im not really sure where to begin there. If you could get me pointed in the right direction (how lualine's window.lua and tab.lua use this formatting for interpreting mouse clicks), I can move towards getting a PR thrown together as a POC.

Read the callback part (@ uses around line 6k ) in :h stl


Update Understanding and configuring Cloudflare Page Rules (Page Rule…

full url example isn't rendering.
use literal code markup so that it will render in webpage.

@pedrosousa is it possible to bypass the spell-check rule?

Yes, I can still merge the PR (once it's ready) even if the spell-checking action fails.

Yes, I can still merge the PR (once it's ready) even if the spell-checking action fails.

Thanks @pedrosousa anything else you need from me. Thanks for being on this. It thrills me that you allow customers to contribute to the docs.

Do you mind committing my suggestion? I can't do it myself in GitHub's web interface (only by checking out the PR locally), since I was the one making the suggestion.


FAQ - Quiestions

Hi There
Firstly as someone who has only recently started learning javascript/typescript, css etc (As I am a back end developer mainly) this was by far the best starting template for me as scadcn is such a great library.
I do have a few questions tho regarding making changes/customising etc as part of learning. Do you have a discord for me to join? The help would greatly be appreciated.

Hey there! I'm not the owner, but feel free to post your questions here. I'll do my best to help out.

@JRebertt Hey, thanks for your reply! I really appreciate your help.


Feature/expect ct

Implement Expect-CT support from #19

About:
Expect-CT is similar to HSTS, where the criteria to fail the TLS connection is lack of certificate transparency.
Draft spec here: https://datatracker.ietf.org/doc/draft-stark-expect-ct/?include_text=1

Changes:

New header by default Expect-CT: max-age=0 to trigger browser warnings
New report if missing entry for Expect-CT
Addition to strictMode Expect-CT: max-age=31536000; enforce
Addition to safeMode for Expect-CT to remove enforce flag: i.e. Expect-CT: max-age=31536000; enforce; report-uri="https://report.exampe.com" => Expect-CT: max-age=31536000; report-uri="https://report.exampe.com"

I'll leave this open and unmerged for any objections/suggestions/comments... to be made until Friday 30th June 2017, or longer if any are outstanding by that time.


Not working for Opera

Not working for Opera. It's working fine with other Chromium-based browsers except the Opera. Can you fix it?

Hello,
Thank you for reporting this issue. I have investigated the problem and confirmed that it fails in both Opera and Opera GX, while it works fine in other Chromium-based browsers. The issue seems to be related to Opera’s handling of the declarativeNetRequest API, which prevents the extension from modifying the headers as expected. However, I have not found any official documentation or discussion about this limitation on Opera’s website or forums.
As a next step, I have posted a question on Opera forums (it is pending approval, I will link to it when it is approved) asking for more information about this, and how to work around it. I will update this issue when I receive a reply or find a solution.
I apologize for any inconvenience this may cause you and appreciate your patience and understanding.
Have a good day.


chore: use @jcoreio/toolchain

:tada: This PR is included in version 3.0.0-beta.13 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket: