When I add to my project as a dependency an another crate I'm working on (and which I have in my kellnr registry) I get a 404 error in Cargo.toml.

[dependencies]
e_gitea = { version = "0.0.4", registry = "my-registry-name" }

Errors
e_gitea: Error: statusCode=404

When I compile the code, it works OK without any problem.

I'm using crates extension v.0.6.6 in Visual Studio Code and I can see in the log it calls Kellnr and gets some answers. However, the result is as it is.

Kellnr log:

  2024-02-21T12:33:27.080411Z DEBUG tower_http::trace::on_request: started processing request
    at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tower-http-0.5.1/src/trace/on_request.rs:80
    in tower_http::trace::make_span::request with method=GET uri=/api/v1/crates/config.json version=HTTP/1.0

  2024-02-21T12:33:27.080962Z DEBUG tower_http::trace::on_response: finished processing request, latency: 0 ms, status: 200
    at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tower-http-0.5.1/src/trace/on_response.rs:114
    in tower_http::trace::make_span::request with method=GET uri=/api/v1/crates/config.json version=HTTP/1.0

  2024-02-21T12:33:27.129706Z DEBUG tower_http::trace::on_request: started processing request
    at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tower-http-0.5.1/src/trace/on_request.rs:80
    in tower_http::trace::make_span::request with method=GET uri=/api/v1/crates/e_/gi/e_gitea version=HTTP/1.0

  2024-02-21T12:33:27.131308Z DEBUG tower_http::trace::on_response: finished processing request, latency: 1 ms, status: 200
    at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tower-http-0.5.1/src/trace/on_response.rs:114
    in tower_http::trace::make_span::request with method=GET uri=/api/v1/crates/e_/gi/e_gitea version=HTTP/1.0

  2024-02-21T12:33:27.209776Z DEBUG tower_http::trace::on_request: started processing request
    at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tower-http-0.5.1/src/trace/on_request.rs:80
    in tower_http::trace::make_span::request with method=GET uri=/api/v1/crates/config.json version=HTTP/1.0

  2024-02-21T12:33:27.210067Z DEBUG tower_http::trace::on_response: finished processing request, latency: 0 ms, status: 200
    at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tower-http-0.5.1/src/trace/on_response.rs:114
    in tower_http::trace::make_span::request with method=GET uri=/api/v1/crates/config.json version=HTTP/1.0

  2024-02-21T12:33:27.255549Z DEBUG tower_http::trace::on_request: started processing request
    at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tower-http-0.5.1/src/trace/on_request.rs:80
    in tower_http::trace::make_span::request with method=GET uri=/api/v1/crates/e_/gi/e_gitea version=HTTP/1.0

  2024-02-21T12:33:27.256316Z DEBUG tower_http::trace::on_response: finished processing request, latency: 0 ms, status: 200
    at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tower-http-0.5.1/src/trace/on_response.rs:114
    in tower_http::trace::make_span::request with method=GET uri=/api/v1/crates/e_/gi/e_gitea version=HTTP/1.0

When I run the request manually
curl -X GET -k -H 'Authorization: MY_TOKEN' -i 'https://my.url/api/v1/crates/e_/gi/e_gitea'

I get a JSON back, but it is invalid (multiple JSON root elements).

Json (I have just removed dependencies so it is not so huge):

{"name":"e_gitea","vers":"0.0.1","deps":[list of dependencies],"cksum":"7caef1326619ccd6a55e29bf00e0d9761d346d1356b3e30f2d89eca0bba23513","features":{},"yanked":false,"v":1}
{"name":"e_gitea","vers":"0.0.2","deps":[list of dependencies],"cksum":"2486b9e3a6a489cbf08b5ab877c035bfd89fb82404532053b164bfb1c9e5b798","features":{},"yanked":false,"v":1}
{"name":"e_gitea","vers":"0.0.3","deps":[list of dependencies],"cksum":"5a1aa74f3d550db57fe8fcbe3434e114e73b5eae47f10d1647183701302e4d37","features":{},"yanked":false,"v":1}
{"name":"e_gitea","vers":"0.0.4","deps":[list of dependencies],"cksum":"f416a536c53323263700a7db35a1c4a45fef43e904ec061d3c37cc6246c33b78","features":{},"yanked":false,"v":1}

So I expect this is the issue?

I'm using version 5.1.3, manual installation.

I'm not sure what's going on, but I'm able to publish smaller crates to a docker container but larger crates are failing.

Docker command to run. Note that bumping KELLNR_REGISTRY__MAX_CRATE_SIZE doesn't appear to help:

docker run --rm -it     -p 8000:8000  -e KELLNR_REGISTRY__MAX_CRATE_SIZE=20 -e KELLNR_LOG__LEVEL=trace -e KELLNR_LOG__LEVEL_WEB_SERVER=trace  ghcr.io/kellnr/kellnr:5.0.0

It looks like there's something in the web stack that's dropping larger requests on the floor, but not leaving any trace in the logs.

    Packaged 96 files, 11.2MiB (4.6MiB compressed)
   Uploading deno_core v0.250.0 (/Users/matt/Documents/github/deno/deno_core/core)
error: failed to publish to registry at http://127.0.0.1:8000

Caused by:
  [55] Failed sending data to the peer (Send failure: Broken pipe)

There are no obvious errors in the logs:

2024-01-24T17:47:26.602933Z DEBUG request: tower_http::trace::on_response: finished processing request latency=1 ms status=200 method=GET uri=/api/v1/crates/se/rd/serde_v8 version=HTTP/1.1
2024-01-24T17:47:26.604148Z DEBUG request: tower_http::trace::on_response: finished processing request latency=2 ms status=200 method=GET uri=/api/v1/crates/de/no/deno_ops version=HTTP/1.1
2024-01-24T17:47:27.891855Z DEBUG request: tower_http::trace::on_request: started processing request method=PUT uri=/api/v1/crates/new version=HTTP/1.1
2024-01-24T17:47:27.928979Z DEBUG request: tower_http::trace::on_response: finished processing request latency=37 ms status=200 method=PUT uri=/api/v1/crates/new version=HTTP/1.1

I followed the instructions https://kellnr.io/documentation, I set the hostname, and I also tried to set it up using an IP, but neither worked for me. I I tried docker, and local serveice, but switched to starting it manully to see the console directly.
When I try to publish empty crate, I will get this error in console:

DEBUG request: tower_http::trace::on_response: finished processing request latency=2 ms status=404 method=GET uri=/api/v1/crates/info/refs?service=git-upload-pack version=HTTP/1.0

When I try to add dependency:
polars = { version = "0.38.1", features = ["csv", "http"], registry = "my-registry" }

DEBUG request: tower_http::trace::on_response: finished processing request latency=0 ms status=404 method=GET uri=/api/v1/crates/info/refs?service=git-upload-pack version=HTTP/1.0

And local error:

fatal: repository 'https://test.bandola.cz/api/v1/crates/' not found
error: failed to get polars as a dependency of package polars_test v0.1.0 (D:\rs\polars_test)
Caused by:
failed to load source for dependency polars
Caused by:
Unable to update registry my-registry
Caused by:
failed to fetch https://test.bandola.cz/api/v1/crates/
Caused by:
process didn't exit successfully: git fetch --force --update-head-ok https://test.bandola.cz/api/v1/crates/ +HEAD:refs/remotes/origin/HEAD (exit code: 128)

if I add the dependency like this:
polars = { version = "0.38.1", features = ["csv", "http"] }

DEBUG request: tower_http::trace::on_response: finished processing request latency=0 ms status=200 method=GET uri=/api/v1/crates/config.json version=HTTP/1.0
DEBUG request: tower_http::trace::on_response: finished processing request latency=1 ms status=404 method=GET uri=/api/v1/crates/po/la/polars version=HTTP/1.0

And local error:

cargo.exe build --color=always --message-format=json-diagnostic-rendered-ansi --package polars_test --bin polars_test
Updating kellnr-cratesio index
error: no matching package named polars found
location searched: registry crates-io
required by package polars_test v0.1.0 (D:\rs\polars_test)

My config.toml:

[registries]
#my-registry = { index = "sparse+https://test.bandola.cz/api/v1/crates/", token = " actual token " }
my-registry = { index = "https://test.bandola.cz/api/v1/crates/", token = " actual token " }

[source.crates-io]
replace-with = "kellnr-cratesio"

[source.kellnr-cratesio]
registry = "sparse+https://test.bandola.cz/api/v1/crates/"
#registry = "sparse+http://192.168.0.112:8000/api/v1/crates/"
#index = "sparse+http://192.168.0.112:8000/api/index/"


[net]
git-fetch-with-cli = true

The commented lines are just some of the examples what I tried. I have token I created in UI there, not " actual token ", but did not want to include that in a public report.

Can you please help me figure out how to set it up correctly? I want it to be mostly internal mirror of crates.io with some private crates.

cargo deny check is a helpful tool to regular check outdated dependencies or

https://github.com/EmbarkStudios/cargo-deny

The advisories check is used to detect issues for crates by looking in an advisory database.
The licenses check is used to verify that every crate you use has license terms you find acceptable.

It might be helpful for this project as well.

Create a statistics page that becomes the default page on the web-ui.

Values to display

• Number of hosted crates
• Number of hosted versions
• Number of downloads
• Number of proxied crates
• Number of proxied versions
• Number of proxied downloads

Misc

• Top downloaded crate (first, second, third)
• Last updated crate

First of all, cool project!

My use case is a CI process which publishes a set of inter-dependent crates to Kellnr to ensure that publishing is possible.

When enabling the crates.io proxy and attempting to publish to the proxy index (e.g. sparse+http://localhost:8000/api/v1/cratesio/), Cargo hangs while waiting for the crate to become available and Kellnr keeps printing the following error:

ERROR index::cratesio_prefetch_api: Could not parse prefetch data from crates.io for test-kellnr: expected value at line 1 column 1

I'm not sure if this is a bug, or the lack of a feature. I would argue that it would be tremendously useful to allow for this.

Download from static.crates.io for cached crates: https://blog.rust-lang.org/2024/03/11/crates-io-download-changes.html

I just noticed that the doc generation queue is accessible when you are not logged in and KELLNR_REGISTRY__AUTH_REQUIRED is set to true. Is that intentional? I think it makes sense to protect this route.

I can't find a way to generate documentation for all features in a crate, it only uses default features.
With crates.io you can do the following in your Cargo.toml:

[package.metadata.docs.rs]
all-features = true

so, maybe support that?

What/Why

Kellnr was started more than three years ago. Rocket.rs was one of the most promising web frameworks at that time. Unfortunatly the development stopped. Axum emerged as a new popular framework with it's roots in the tokio ecosystem, which makes it a perfect fit for Kellnr, as tokio is already heavily used.

To Do

Kellnr uses rocket.rs for routing, authentication and serving static files. All of this has to be migrated. The list below gives an overview of what has to be done.

The behavior should not change to make the migration as smooth as possible. For nearly all APIs multiple corresponding tests exist.

Contribute

The branch migrate-to-axum is used. If you intend to help with the migration, fork the project and use this branch as the base for your work. Please check the migrated APIs below, such that it is clear what is still missing and work is not done multiple times.

Root - UI

The root serves mostly UI related APIs.

API

• ui::kellnr_version
• ui::crates
• registry::kellnr_api::me
• ui::search
• ui::statistic
• web_ui::settings::settings
• ui::crates_data
• ui::cratesio_data
• ui::delete
• ui::build_rustdoc

Tests

• ui::kellnr_version
• ui::crates
• registry::kellnr_api::me
• ui::search
• ui::statistic
• web_ui::settings::settings
• ui::crates_data
• ui::cratesio_data
• ui::delete
• ui::build_rustdoc

Static File Server

This route serve static file content, e.g. the user interface for Kellnr.

API

• "/" -> serves "./static"

User

The user API manages all things related to Kellnr users, for example creating a user or adding a authentication token.

API

• user::login
• user::logout
• user::change_pwd
• user::add
• user::delete
• user::delete_forbidden (still needed?)
• user::reset_pwd
• user::add_token
• user::delete_token
• user::list_token
• user::list_users
• user::login_state

Tests

• user::login
• user::logout
• user::change_pwd
• user::add
• user::delete
• user::delete_forbidden (still needed?)
• user::reset_pwd
• user::add_token
• user::delete_token
• user::list_token
• user::list_users
• user::login_state

Crates

The API for the crates are implemted under /api/v1/crates. This is the heart of Kellnr and allows cargo to push and pull crates.

API

• index::kellnr_prefetch_api::prefetch_kellnr
• index::kellnr_prefetch_api::prefetch_len2_kellnr
• index::kellnr_prefetch_api::config_kellnr
• registry::kellnr_api::download
• registry::kellnr_api::publish
• registry::kellnr_api::yank
• registry::kellnr_api::unyank
• registry::kellnr_api::search
• registry::kellnr_api::list_owners
• registry::kellnr_api::add_owner
• registry::kellnr_api::remove_owner

Tests

• index::kellnr_prefetch_api::prefetch_kellnr
• index::kellnr_prefetch_api::prefetch_len2_kellnr
• index::kellnr_prefetch_api::config_kellnr
• registry::kellnr_api::download
• registry::kellnr_api::publish
• registry::kellnr_api::yank
• registry::kellnr_api::unyank
• registry::kellnr_api::search
• registry::kellnr_api::list_owners
• registry::kellnr_api::add_owner
• registry::kellnr_api::remove_owner

Crates.io

Kellnr can proxy and cache crates.io, as such it dublicates the crates API from above for crates.io

API

• index::cratesio_prefetch_api::prefetch_cratesio
• index::cratesio_prefetch_api::prefetch_len2_cratesio
• index::cratesio_prefetch_api::config_cratesio
• registry::cratesio_api::download
• registry::cratesio_api::search
• ui::delete_cratesio_index

Tests

• index::cratesio_prefetch_api::prefetch_cratesio
• index::cratesio_prefetch_api::prefetch_len2_cratesio
• index::cratesio_prefetch_api::config_cratesio
• registry::cratesio_api::download
• registry::cratesio_api::search
• ui::delete_cratesio_index

Not Found

Forward all not found pages to the vue.js router.

• "not found" -> "/static/index.html" -> The vue.js router will take over from here

I want to ask, do the Kellnr application has any metrics, and if there any plans to implement them? For example, Meuse exposes a Prometheus endpoint with various metrics.

So, I can implement Prometheus metrics exporter on top of the prometheus-client library and send a PR.

Create a config to allow only specific SPDX licenses to be downloaded by Kellnr. If a crate with a different license is requested, don't allow the download.

Use-Case: Companies that do not want gpl code but only MIT or Apache.

Currently, the Kellnr UI only supports desktop browser and doesn't scale down to mobile devices.

Create a reactive UI that looks good on desktop and mobile.

Hi there,

I tried out kellnr yesterday at work, since we are looking for an out-of-the-box solution for a private Rust registry that supports serving documentation. The initial setup using Docker Compose was actually very easy and a quite pleasant experience. The webinterface has a nice aesthetic and it has all features that I'd initially expect. However, some parts of it are a little odd user experience wise. For example, it feels weird that the login page just tells me that I've successfully logged in, but it doesn't redirect me to somewhere that would make sense, like the dashboard or the settings. It also feels weird that various parts of the interface don't update when you navigate away from the page and back. When I want to see up-to-date data, I have to refresh the entire site.

The big problem I have with kellnr however is that the docs and also a lot of other information about the published crates are public and not guarded by authentication. Is that on purpose or a bug?

While it's not overly important to protect generic information about a crate, like its name, versions or dependencies, the docs definitely are. Rustdocs not only give deep insight into the source code, but it also allows looking at the source code itself. This makes the required authentication for pulling crates basically useless, since anyone could just get hold of the source code via the docs.

If we wanted to use kellnr as it is right now, we would have to use some other authentication layer on top, to protect the sensitive information. While this is a possible solution, it's certainly not a nice one and to be honest, I wouldn't expect to have to do something like this for a software that advertises itself "to keep my code truly private".

Is there a way to have Kellnr return the latest version of a crate for docs? In other words, something like

http://{Kellnr host}/api/v1/docs/{crate name}/latest

which would redirect to whatever the latest version is? If not, would a PR to enable such functionality be acceptable?

Add a toggle to show crates from crates.io in the UI, too.

Update the helm chart and docu for v5. Write a short migration docu.

I found I keep getting checksum failed for the same crates when I have tried re-running the cargo check. And after deleting the cached package in kellnr, and download again, it works.

I suppose the checksum should be verified after add_package here, and re-download if it doesn't match the crates.io 's checksum.

crates upload body limit is not set in axum, the setting crates/max_crate_size in default.toml is not working

Display the needed config piece for Cargo to use the current Kellnr instance prominently in the UI.

• Copy with one click on a button
• Depending on the enabled features (proxy, required auth) show different config

For example:

Copy this code to your .cargo/config.toml to use this Kellnr instance

[registries]
kellnr = {index = "sparse+https://kellnr.com/api/v1/crates", token = ""}

# IF PROXY IS ENABLED
[source.crates-io]
replace-with = "kellnr-cratesio-sparse"

[source.kellnr-cratesio-sparse]
registry = "sparse+https://kellnr.com/api/v1/cratesio/"

# IF REQUIRED AUTH IS ENABLED
# https://doc.rust-lang.org/nightly/cargo/reference/registry-authentication.html
[registry]
global-credential-providers = ["cargo:token"]

Hi,

I'm trying to setup kellnr 5.1.1 to use as a proxy for crates.io, however, when I try to run cargo fetch I get the following error:

$ cargo fetch
    Updating `kellnr-cratesio` index
error: failed to select a version for the requirement `ahash = "^0.8"`
candidate versions found which didn't match: 0.4.0, 0.3.8, 0.3.7, ...
location searched: `kellnr-cratesio` index (which is replacing registry `crates-io`)
required by package `sqlx-core v0.7.0`
    ... which satisfies dependency `sqlx-core = "=0.7.0"` of package `sqlx v0.7.0`
    ... which satisfies dependency `sqlx = "^0.7"` of package `config-rest-service v2024.1.28 (/home/pcampbell/projects/tasyn/main/crates/services/config-rest-service)`
    ... which satisfies path dependency `config-rest-service` of package `tasyn v2024.1.28 (/home/pcampbell/projects/tasyn/main/crates/main)`
perhaps a crate was updated and forgotten to be re-vendored?

This works when my ~/.cargo/config is unmodified and is contacting crates.io directly.

When I add the following to ~/.cargo/config I get the error as above:

[registries]
kellnr = { index = "sparse+https://********:443/api/v1/crates/", token = "***" }
[source.crates-io]
replace-with = "kellnr-cratesio"
[source.kellnr-cratesio]
registry = "sparse+https://********:443/api/v1/cratesio/"

When I inspect the cratesio_index table within the sqlite database, I can see that only the first ~49 versions of the ahash crate have been added to the database.

https://blog.rust-lang.org/2024/02/06/crates-io-status-codes.html

Finally, crates.io will return sane http status codes, instead of 200 for errors.

Implement the changes, such that kellnr does return the new status codes, too.

Pressing the build button in documentation from the WebUI gives the following error:

ERROR docs::doc_queue: Failed to extract docs from crate: could not execute process `rustc -vV` (never executed)

I have full rust stable toolchain installed:

$ rustc -vV
rustc 1.75.0 (82e1608df 2023-12-21)
binary: rustc
commit-hash: 82e1608dfa6e0b5569232559e3d385fea5a93112
commit-date: 2023-12-21
host: aarch64-unknown-linux-gnu
release: 1.75.0
LLVM version: 17.0.6

$ rustdoc -V
rustdoc 1.75.0 (82e1608df 2023-12-21)

Update the installer script for Kellnr v5 and document the changes in the docs on the website.

Description

I have noticed a bug in an UI. When I go to the "search" page and enable listing cached crates there is an inconsistency between view with empty search query, and with filtered crates. When the search input is empty, to the right of each crate name there is its version number, and to the bottom of it a link to its documentation (on docs.rs):

But after filtering out crates using search version number is replaced with "vnone", and link to the documentation is replaced with a link to /publishdocs.

This only affects cached crates from crates.io.

Version

Kellnr 5.2.0

Kellnr supports the git index and the sparse index protocol. As of cargo 1.70, the sparse protocol is the default. The git index has only disadvantages and needs a lot of maintenance. To keep the code base small, remove the feature as the sparse index is the future.

• Remove kellnr git index code
• Remove crates.io git index code
• Remove code to start git-daemon
• Remove git index settings code
• Remove git index documentation
• Set minimal required cargo version in docs, to support only the sparse index
• Remove delete git index page from web ui

It would be very useful for me to be able to hide crates list and their metadata from the ui with a setting in the config if a user is not logged in

I'm trying to deploy a kellnr instance behind a proxy that forces https traffic.

My current configuration is:

KELLNR_API_ADDRESS=example.com
KELLNR_API_PROTOCOL=https
KELLNR_API_PORT=8000
KELLNR_API_PORT_PROXY=443

My assumption here is that the kellnr instance behind the proxy would communicate with the proxy on port 8000 and users would go through the proxy and requests would be done to https://example.com:443/api/v1/crates. The issue is that when building the ConfigJson object only the api_port setting is used.

Am I correct in assuming that it should check if api_port != api_port_proxy and use the latter instead?

This is the current response of /api/v1/crates/config.json with the configuration above:

{
  "dl": "https://example.com:8000/api/v1/crates",
  "api": "https://example.com:8000",
  "auth-required": false
}

I'd expect it to be:

{
  "dl": "https://example.com:443/api/v1/crates",
  "api": "https://example.com:443",
  "auth-required": false
}

Currently, only one version of a crate can be delete at a time in the UI.

TODO: Add a button to delete all versions of a crate at a time.

We intermittently get warning: spurious network error (1 tries remaining): [28] Timeout was reached (Operation too slow. Less than 10 bytes/sec transferred the last 30 seconds)

We have installed kellnr on EKS through helm.

I have a droplet setup and Im running kellnr in order to cache crates on that server so that I dont have to refetch them afterwads for other projects.
This container is running on my remote server:

docker run --rm -it     -p 8000:8000     -e "KELLNR_ORIGIN__HOSTNAME=hostip"     -e "KELLNR_SETUP__ADMIN_TOKEN=my_super_secret_auth_key"     -e "KELLNR_PROXY__ENABLED=true"     -v $(pwd):/opt/kdata ghcr.io/kellnr/kellnr:5.0.0

and this is my .cargo/toml file:

[source.crates-io]
replace-with = "kellnr-cratesio"
[source.kellnr-cratesio]
registry = "sparse+http://hostip:8000/api/v1/cratesio/"

When I build the project, I get:

error: failed to download replaced source registry `crates-io`
Caused by:
 failed to verify the checksum of `bitflags v1.3.2 (registry `kellnr-cratesio`)`

It is properly caching crates from crates.io, since the crates/ directory gets populated (but fails when downloading the bitflags crate). I've also checked with other projects as well and it fails with other crates as well (not necessarily bitflags).

Hi the company I work at is adverse to hosting things by themselves. Are there any plans for commercial support for hosting a private kellnr instance, or companies that offer this.

The Company considers hosting a VM or docker instance, "self-hosting".

Just to be clear, this is not me guaranteeing that the company would go for this if that was the case, only that it would be more likely if it was a SaaS.

As mentioned in #91, after a successful login, Kellnr does not forward the user to the main page, but instead stays on the "successful login" page.

If the login is done from the settings page, the user if forwarded to the settings page. Equivalent to this behavior, forward the user after a login from the main (or any other page) back to the main page.

When incorrect password is entered internal server error message is displayed instead of incorrect username or password message.

Message in log:
ERROR web_ui::error: Db: PasswordMismatch
ERROR tower_http::trace::on_failure: response failed classification=Status code: 500 Internal Server Error latency=2 ms

It would be great to be able to set permissions to push and pull for every user for every crate or for group of users and group of crates

Hi,
I configure a private registry behind apache (to have SSL connections) that works with sparse+https protocol. But I struggle on it and on client side I will obtain only the error "config.json not found in registry".
Here is a snippet on client:

$ cargo -V
cargo 1.73.0
$ cargo login --registry=kellnr      
    Updating `kellnr` index
error: config.json not found in registry

On server:

1. Install Apache 2.4.52 and configure a VHOST with SSL on port 443 (with certificate and key) with these configs:

    ProxyPreserveHost On
    ProxyPass / http://localhost:8443/
    ProxyPassReverse /	http://localhost:8443/

2. install kellnr (last attempt with version 4.0.3) in /opt/kellner-4.0.3 with the following options:

# Address where Kellnr will be reachable
# E.g. https://kellnr.example.com:443
api_address = "https://<myURL>"
# The port where Kellnr starts listening for incoming connections
api_port = 8443
# If a proxy is used in front of Kellnr, the port of the proxy can be specified here
# If no proxy is used, it is the same as the "api_port"
api_port_proxy = 443
# Either "https" or "http". Use in combination with a reverse proxy that provides HTTPS.
api_protocol = "https"

# Directory where Kellnr stores all its data, e.g. crates, incides etc.
data_dir = "/data/kellnr"

# Address where the crates index is reachable. Usually no change is needed.
index_address = "0.0.0.0"
index_port = 9419

# Seconds until a user is logged out automatically after inactivity in the UI
session_age_seconds = 28800

# Address where the API and web server is started. Usually no change is needed.
web_address = "0.0.0.0"

...

# Enable git index (needed for cargo < 1.70)
# Enabling the git index will increase the memory usage of Kellnr and requires a lot of disk space.
# If you pushed crates before enabling the git index, they will not be available in the git index but
# only in the sparse index. You can reindex them by deleting the crates from the sparse index and pushing
# them again.
git_index = false

kellnr is than launched with a systemd service and I see running and listening on port 8443.

On server I see those messages in the log:

kellnr[153519]: 2023-11-08T10:07:21.329138Z  WARN rocket::response::responder::_: Response was `None`.
kellnr[153519]: 2023-11-08T10:07:21.329166Z ERROR rocket::server::_: No matching routes for GET /api/v1/cretes/config.json text/plain.
kellnr[153519]: 2023-11-08T10:07:21.329202Z  WARN rocket::server::_: Responding with registered (not_found) 404 catcher.

I can reach the website and all page looks working on HTTPS://, and also HTTP://:8433 but cargo publish and login will fail with both address.
I tried cargo on an old kellnr 3.2.0 with git enabled on the same server (ports 8000 and 9148) and it works.

What I'm doing wrong?
Thanks for the help,
Davide

I noticed that Kellnr uses the crates folder in the data directory to store all the cached crates from crates.io. Wat worries me is that it also stores the locally published crates in that directory. Doing this may lead to name clashes.

Did I miss something in configuration or is this intended?

Would be a nice feature to allow us to see the packages cached by the proxy feature and the count/downloads in the web UI.

Also, it appears these are stored in a different directory from the local crates. What directory do they live in as I'd like to add a docker volume to store those to not lose them in container restart.

The current settings to configure the address and port where Kellnr runs is confusing.

• web_address at start-up as the address
• The port api_port sets where Kellnr runs locally
• The api_address does not set the address where Kellnr runs locally, but where it is reachable from the outside
• The api_port_proxy is the port for external reachability
• The api_protocol is for external usage, too

Refactor the settings to make it more clear, what means what.

Idea:

[local]
# Address where Kellnr binds to. Usually, no change is needed.
address = "0.0.0.0"
# Port where Kellnr binds to.
port = 8000

[external]
# Host from which Kellnr is reachable from the outside.
host = "127.0.0.1"
port = 8000
protocol = "http"

just started trying out kellnr here and clicking through the web-ui, i was wondering if one could list the dependees of a package in addition to the dependencies. (possibly also transitive dependees). such that if i'm about to update a package, i can check "who uses this api?" "whom should i poke to migrate to a new api?" "which functions aren't used by anyone?" "which packages should i urgently re-build because of a security issue?". no strong preference here about what would be a good play to provide that information, crates.io has 'dependents' as tab next to 'dependencies' and 'versions' and 'readme', but that's just one option.

I tried updating the helm values (default.toml) but kellnr will not update the changes. I even tried to manually update the configmap and then run helm but the values stayed the same. In order to get the default.toml to change, I had to manually update configmap and then restart the deployment in kubernetes for changes to take effect. I believe this isn't the way it should be done

I've set admin password through KELLNR_SETUP__ADMIN_PWD env variable and admin_pwd param in the toml config. But I'm getting internal server error trying to log in as admin with configured password. Furthermore, admin password is still working

Hi, bro. Currently, kellnr can only proxy https://crates.io/. Can it support proxying other mirror addresses? Just like the nexus proxy for pypi etc. Can it be configured in the configuration file?

What could be the cause for failing doc builds inside the container?

Invalid cross-device link (os error 18), while trying to rename
from /root/.rustup/toolchains/... to /root/.rustup/tmp/...
does not make sense, because this is the same filesystem as I understand it.

Any ideas?

Thanks for kellnr, by the way. It's great!

Running `rustc --crate-name regex --edition=2021 
/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/regex-1.10.4/src/lib.rs 
--error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat 
--crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no 
--cfg 'feature="std"' --cfg 'feature="unicode-perl"' 
-C metadata=acec26d0b77f6756 -C extra-filename=-acec26d0b77f6756 
--out-dir /opt/kdata/doc_queue/cRvqR6YjeT/mylib-sys-2.4.0/target/debug/deps 
-L dependency=/opt/kdata/doc_queue/cRvqR6YjeT/mylib-sys-2.4.0/target/debug/deps 
--extern regex_automata=/opt/kdata/doc_queue/cRvqR6YjeT/mylib-sys-2.4.0/target/debug/deps/libregex_automata-f6805926912f666c.rmeta 
--extern regex_syntax=/opt/kdata/doc_queue/cRvqR6YjeT/mylib-sys-2.4.0/target/debug/deps/libregex_syntax-5957eeb6d1504fb2.rmeta --cap-lints allow`
info: removing previous version of component 'cargo'
info: rolling back changes
error: could not rename component file from 
'/root/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/share/doc/cargo' to
'/root/.rustup/tmp/xrl8fy9awgv8lkcy_dir/bk': Invalid cross-device link (os error 18)
error: could not compile `proc-macro2` (build script)

Hi. I wanted to ask about S3 support - is it planned? I think it could be very useful in environments where it is available. For example in my current environment I have no access to any kind of persistent storage unfortunately, so deploy in k8s is out of question. For example https://github.com/mcorbin/meuse supports it (we currently use it, but it is lack certain features like docs generation and user management in UI, also written in Clojure so hacking it is much harder).

If you ok with it, I will try to implement it and send a PR.

Was thinking it'd be nice to have kellnr hit a webhook or run a script upon successful publish, notifying of newly published crate/version to something like Slack.

Add a search bar to the landing page and forward to the crates overview on search.

Hello!

Great project!

I'm using 5.0.0 version and faced with problem: I'm unable to delete crate from UI
What I did:

1. Login as admin
2. Find crate to be deleted from start page
3. Click on Admin -> Delete
4. Confirm deleting on pop-up window

What I expected:
Crate is deleted

Real behaviour:
Nothing changed. Crate is still here

What are in logs (I masked real crate name with ***) :

2024-01-15T09:48:38.523969Z DEBUG request: tower_http::trace::on_response: finished processing request latency=4 ms status=200 method=POST uri=/api/v1/user/login version=HTTP/1.0
2024-01-15T09:49:11.762078Z DEBUG request: tower_http::trace::on_request: started processing request method=GET uri=/api/v1/ui/crate_data?name=*** version=HTTP/1.0
2024-01-15T09:49:11.765996Z DEBUG request: tower_http::trace::on_response: finished processing request latency=3 ms status=200 method=GET uri=/api/v1/ui/crate_data?name=*** version=HTTP/1.0
2024-01-15T09:49:31.342087Z DEBUG request: tower_http::trace::on_request: started processing request method=DELETE uri=/api/v1/ui/delete_crate?name=***&version=1.231115.0-dev version=HTTP/1.0
2024-01-15T09:49:31.358934Z DEBUG request: tower_http::trace::on_response: finished processing request latency=16 ms status=200 method=DELETE uri=/api/v1/ui/delete_crate?name=***&version=1.231115.0-dev version=HTTP/1.0

Currently, if the "authentication on pull" feature is enabled, any user (logged in or not) can see the crates, docs and so on in the UI. That renders the authentication feature rather useless, as the code of the crates can be seen in the docs anyway.

Implement: If the "authentication on pull" is enabled, require a login to the UI and do not show any data to anonymous users.