如果 Discourse 实例已经接入了 Anthropic。 那么只需要在后台挑一个不希望继续使用的模型改下就好。 否则需要重新在 Discourse 实例中配置 AI，然后获得 Anthropic 的 key。 进入后台的 AI 然后选择 LLMs     虽然我们这里已经显示成 3.7 了，但实际上所有内容都是从 3.0 改的。 单击后面的编辑。 LLMs 在 Name中输入：Claude 3.7 Sonnet 用于区分其他模型。     随后保存提交，同时还可以进行测试。 如果测试没有问题则会显示成功。 Discourse 测试 对于新的模型可以在 Discourse 中进行测试。 选择定义的新模型，如果模型名字没有刷新，那么有可能缓存问题，可以强制刷新下页面和退出登录后重新登录。     校验 API 调用 登录 Anthropic 后台查看下使用量。 确定已经有模型 3.7 的使用量，那么则说明调用配置成功了。     在 Discourse 中添加模型挺简单的，基本上可以无缝集成不同的模型。   https://www.isharkfly.com/t/discourse-claude-3-7-sonnet/16987

自从 CentOS 不再提供技术支持，并且 RHEL 希望所有使用免费版本的 Linux 用户切换到 Fedora，并且能够为 RHEL 的商业服务提供销售。 我们也进行了多次的服务器切换。 最近的决定是将 Fedora 的部署， 逐步完全切换到 Ubuntu。 其主要原因就是支持时间长短的问题。 对于很多初创型企业是没有办法购买 REHL 的商业服务，所以他们更多依赖免费的开源社区。 支持周期 Fedora 的支持周期只有 13 个月。   对于部署并且运行的服务器，如果不是服务器版本支持的问题，通常我们是不会升级服务器的操作系统。 因此只有 13 个月的支持周期显然太短了，我们不可能每 13 个月就去升级下操作系统，重装一下，进行一次数据迁移。 这是完全不现实。 Ubuntu 的支持周期显然就长得多， 24.04 的支持可以到 2036 年，超过了 10 年。     针对不少使用 Linux 的企业来说，基本上在生命周期内不用担心升级的问题。 这也是我们放弃 Fedora 切换到 Ubuntu 的主要原因。   https://www.isharkfly.com/t/fedora-ubuntu/16956

在 pgAdmin 4 界面中选择 Tools 下面的工具，然后选择 PSQL Tool 工具     另外的，还可以在项目浏览器中选择右键，然后单击 PSQL Tool 工具。     随后在弹出的界面中可以看到 PSQL 的工具。     随后，可以在界面中输入 SQL 进行查询： select * from pg_namespace;     当然，也可以使用其他的工具来运行 SQL。   https://www.isharkfly.com/t/pgadmin-4-psql-tool/16926  

最新版本的 Excel 中提供了 Python 的功能，虽然现在还只是预览。 对于所有的计算机，可以直接在 Excel 中测试下代码。     能够实现函数就直接调用了。     看这是打算玩死其他 Python 环境呀。 https://www.isharkfly.com/t/excel-python/16905

当对 Discourse 更新数据库后，新的 PostgreSQL 数据库没有 statistics 表。 你可以使用下面的命令来生成 statistics 表。 cd /var/discourse ./launcher enter app su postgres psql \connect discourse VACUUM VERBOSE ANALYZE; \q exit exit 当然，你可以可以在 SSH 到服务器上直接运行下面的命令： /var/discourse/launcher run app "echo 'vacuum verbose analyze;' | su postgres -c 'psql discourse'" 建议使用单一命令行进行执行。   https://www.isharkfly.com/t/discourse-postgresql/16903

在 Discourse 数据库进行升级后的主要特性就是对 Discourse 数据库中使用的索引进行优化。 Discourse 中的索引主要使用的是post_timings 表和数据库的索引。 当对数据库升级完成后，需要针对数据库运行下面的命令来对数据库的索引进行优化和重建。 cd /var/discourse ./launcher enter app su postgres psql \connect discourse REINDEX SCHEMA CONCURRENTLY public; \q exit exit 当完成上面的命令后，可以检查下 post_timings 的大小来查看数据库重构索引后的数据库数据大小变化。   2025-02-10_22-22-151226×847 130 KB   也可以使用下面的命令来对数据库进行查询，下面的 SQL 查询将会返回你当前运行 Discourse 实例中 20 个最大的数据对象。 可以在索引重建之前和之后都运行下来比较大小。 WITH RECURSIVE pg_inherit(inhrelid, inhparent) AS (select inhrelid, inhparent FROM pg_inherits UNION SELECT child.inhrelid, parent.inhparent FROM pg_inherit child, pg_inherits parent WHERE child.inhparent = parent.inhrelid), pg_inherit_short AS (SELECT * FROM pg_inherit WHERE inhparent NOT IN (SELECT inhrelid FROM pg_inherit)) SELECT table_schema , TABLE_NAME , row_estimate , pg_size_pretty(total_bytes) AS total , pg_size_pretty(index_bytes) AS INDEX , pg_size_pretty(toast_bytes) AS toast , pg_size_pretty(table_bytes) AS TABLE FROM ( SELECT *, total_bytes-index_bytes-COALESCE(toast_bytes,0) AS table_bytes FROM ( SELECT c.oid , nspname AS table_schema , relname AS TABLE_NAME , SUM(c.reltuples) OVER (partition BY parent) AS row_estimate , SUM(pg_total_relation_size(c.oid)) OVER (partition BY parent) AS total_bytes , SUM(pg_indexes_size(c.oid)) OVER (partition BY parent) AS index_bytes , SUM(pg_total_relation_size(reltoastrelid)) OVER (partition BY parent) AS toast_bytes , parent FROM ( SELECT pg_class.oid , reltuples , relname , relnamespace , pg_class.reltoastrelid , COALESCE(inhparent, pg_class.oid) parent FROM pg_class LEFT JOIN pg_inherit_short ON inhrelid = oid WHERE relkind IN ('r', 'p') ) c LEFT JOIN pg_namespace n ON n.oid = c.relnamespace ) a WHERE oid = parent ) a ORDER BY total_bytes DESC LIMIT 20; https://www.isharkfly.com/t/discourse/16904

用户自定义字段能够让你在用户注册的是要求用户提供更多的信息。这些用户提供的信息可以在用户名片，用户摘要页面下显示，甚至还可以通过 Data Explorer plugin 插件进行查询。 本文能够帮助你对这些字段进行配置和设置。 添加一个用户字段 进入 Admin > Community > User Fields (discourse.example.com/admin/config/user-fields). 如果你还没有创建过用户字段的话，显示下面的界面：   单击 “Add user field” 按钮来创建一个新的字段。   选择一个字段类型 选择的字段类型将会决定用户在注册的时候可以输入的内容。 选择的字段类型基于你想获得用户的什么信息，通常用下面的一些选择： Text（文本字段） 这个字段用户可以输入自己想输的内容，通常针对的是有多种回答的问题 (例如： “What company do you work for?”) 在文本输入的时候显示 HTML 确认 主要针对我们常用的 yes/no 问题，(例如, “Would you like to sign up for our newsletter?”) 显示为 HTML checkbox（选择项） 下拉选择 如果你希望提供多个可以供用户选择的话 (例如, “What is your gender?”) 显示为 HTML select input（选择输入） 针对下拉选择字段添加可选的下拉选择项目： 单击可选输入 输入一个回答后单击 “Create” 重复上面的过程 完成后的下拉选择项，看起应该和下面的图片内容相似：     设置字段名和描述 Field Name（字段名）:在用户注册表单和用户属性之前进行显示 Field Description（字段描述）: 显示在用户可以输入的内容之后，用于帮助用户理解这个字段的内容和意义。 字段名和字段描述在添加字段的时候是必须的，这 2 个字段不能留空。 当完成上面的设置后，下面的界面显示了用户在注册的时候看到的情况：     配置用户字段选项 字段必须 Optional（可选） - 用户针对这个可选的字段可以不输入内容 For all users（针对所有用户） - 当这个字段是针对所有用户都要求的话，所有的用户都要求在登录的时候进行选择。针对这个选项比如说 terms-of-service (ToS) 就可以进行选择 On signup（在注册的时候） - 所有新注册的用户都需要对这个字段进行处理 在当前的用户创建界面的地步，用户还有下面的一些选项可以进行选择： Editable after signup（注册后可以编辑）: 当字段内容被创建后，用户还是可以进行编辑 Required at signup（注册时必填）: 当用户在创建自己账号的时候，这个字段的内容必填 Show on public profile（在用户公开属性中显示）: 字段中输入的内容将会在用户摘要页面可见 Show on user card（在用户名片中显示）: 在用户选项卡中显示字段值 Searchable（可以搜索）: 用户在字段中输入的值可以在用户目录中进行搜索 在公开属性中显示 当这个选项被启用，用户字段的值将会显示在用户的属性页面中：     在用户名片中显示 当这个选项被启用，用户字段中的值将会显示在用户名片中显示：     可被查询 当这个选项被启用，你可以基于这个字段中的值来搜索用户： 保存和编辑字段 单击"Save（保存）" 来将用户字段添加到你的用户站点中。 如想对添加后的字段进行编辑，单击 “Edit（编辑）” 列表中的编辑按钮。 如需删除字段，单击 “Delete（删除）” 按钮。     添加自定义字段到用户目录 进入用户目录 单击扳手按钮： 选择你希望显示的用户字段 单击"Save（保存）"     选择的自定义字段将会显示在用户目录表中：   https://www.isharkfly.com/t/discourse/16901

WARNING! 如果你的数据库很大的话，你需要很多的磁盘空间才能完成升级操作（至少需要 2 倍空闲的当前数据库空间），并且在升级的时候需要小心，同时先完成备份后再升级。 Discourse 的官方已经完成了对 Discourse 容器的修改，当 Discourse 的管理员对容器进行重构的话，最新的 Discourse 版本将会自动升级数据库到 PostgreSQL 15。虽然这次升级是从 PostgreSQL 13 到 PostgreSQL 15，如果再 2020 年的时候，你的 Discourse 按照实例没有升级到 PostgreSQL 13（PostgreSQL 13 update - Announcements - Discourse Meta ），你可以跳过这个升级过程，直接升级到 PostgreSQL 15。 如果在本次升级之前，你都没有升级过 PostgreSQL 数据库，那么你可以把 Discourse 的配置文件从 templates/postgres.12.template.yml 修改为 templates/postgres.template.yml，上面的配置文件是在 app.yml 中定义的。 针对任何数据库或系统的升级，我们 强烈建议 对需要升级的实例进行备份。 多备份，多备份不是坏事。 升级 官方支持的 Discourse 安装指南 (单容器安装) 在你下一次对你的 Discourse 重构的时候，你将会在重构中看到下面的提示： ------------------------------------------------------------------------------------- UPGRADE OF POSTGRES COMPLETE Old 13 database is stored at /shared/postgres_data_old To complete the upgrade, rebuild again using: ./launcher rebuild app ------------------------------------------------------------------------------------- 当看到上面的消息，说明这次升级非常顺利，所有的数据库升级都已经完成了，你只需要重构 Discourse 安装实例即可。 我们也才完成了升级：2025年2月的 Discourse 版本重构后会升级 PostgreSQL 到15 整体的升级过程还是非常丝滑，没有什么太大的问题。 数据中心安装 如果你的 Discourse 安装是通过数据中心容器方式进行安装的，这种方式的安装是通过 Discourse 官方提供的 discourse_docker 仓库进行安装的话，你需要以安装的方式关闭 PostgreSQL 服务。 当前，我们会有后台运行的查询来对数据库每隔几分钟就会进行下查询。因此关闭 Web 容器将会有助于数据库容器的正常关闭。 ./launcher stop web_only ./launcher stop data ./launcher rebuild data ./launcher rebuild data ./launcher rebuild web_only 在对数据容器进行重构之前，你可以查看下 PostgreSQL 日志，以确定数据库容器被正确的关闭。 运行 tail -f shared/standalone/log/var-log/postgres/current 命令，如果能看到下面的输出，则说明数据库容器被正确的关闭： 2025-01-24 09:19:06.437 UTC [37] LOG: received smart shutdown request 2025-01-24 09:19:06.444 UTC [37] LOG: background worker "logical replication launcher" (PID 54) exited with exit code 1 2025-01-24 09:19:06.446 UTC [49] LOG: shutting down 2025-01-24 09:19:06.468 UTC [37] LOG: database system is shut down 进行手动更新 / 磁盘空间检查 在对这些进行操作之前，请务必备份 POSTGRES_DATA 目录 如果当前的磁盘空间有限，但你也没有办法获得更多的磁盘空间的话，可以尝试下下面的方法：following: ./launcher stop app #(or both web_only and data if that is your case) mkdir -p /var/discourse/shared/standalone/postgres_data_new docker run --rm \ --entrypoint=/bin/bash \ -v /var/discourse/shared/standalone/postgres_data:/var/lib/postgresql/13/data \ -v /var/discourse/shared/standalone/postgres_data_new:/var/lib/postgresql/15/data \ tianon/postgres-upgrade:13-to-15 \ -c "apt-get update && apt-get install -y postgresql-13-pgvector postgresql-15-pgvector && docker-upgrade" mv /var/discourse/shared/standalone/postgres_data /var/discourse/shared/standalone/postgres_data_old mv /var/discourse/shared/standalone/postgres_data_new /var/discourse/shared/standalone/postgres_data docker run --rm -v /var/discourse/shared/standalone:/shared \ local_discourse/app chown -R postgres:postgres /shared/postgres_data #(or local_discourse/data) ./launcher rebuild app #(or first data and then web_only if that is your case) 在官方的数据库升级测试情况下，至少需要有超过当前数据库使用空间 1 倍以上的空闲空间才可以。 建议是需要保留至少 2 倍以上的空闲空间。 如果你使用的不是默认的路径，你可以尝试下面的命令来替换下 docker 命令： # change…

错误提示的界面如下。     问题和解决 这个问题的原因在于我们有一次在对系统进行服务器迁移的时候。 我们的数据库和软件都已经正常恢复了，但是老的代码仓库因为磁盘空间的问题没有拷贝到新的服务器上。 因此只需要把老的仓库拷贝到新服务器上，让程序能够从磁盘上读取文件就可以修复这个问题。 当把代码文件夹从远程拷贝过来后直接刷新。     可以看到代码正常恢复。 https://www.isharkfly.com/t/gitea-repository-cannot-be-read/16888

系统时时刻刻都在产生日志，如果不及时清理，很快就会灌满硬盘，但如果要手工清理，又很麻烦。 这种情况下，logrotate 这个程序很好的完成这个任务。 logrotate 用来把旧的日志文件删除，并创建新的日志文件，我们把它叫做“转储”。 我们可以根据日志文件的大小，也可以根据其天数来转储，这个过程一般通过一个叫做crond的守护进程来执行，logrotate 还可以用于压缩日志文件，以及发送日志到指定的E-mail 。 logrotate 的配置文件是 /etc/logrotate.conf。 查看当前版本 在系统中使用命令来查看版本： logrotate --version   一些使用的方法，请参考下面的内容： 查看使用手册 man logrotate     nginx 日志归档 在默认情况下，操作系统已经为我们配置了 nginx 的默认日志归档。 归档的配置文件为： /etc/logrotate.d/nginx 可以直接编辑这个文件。 /var/log/nginx/*.log /var/log/nginx/src.isharkfly.com/*.log { daily missingok rotate 14 compress delaycompress notifempty create 0640 www-data adm sharedscripts prerotate if [ -d /etc/logrotate.d/httpd-prerotate ]; then \ run-parts /etc/logrotate.d/httpd-prerotate; \ fi \ endscript postrotate invoke-rc.d nginx rotate >/dev/null 2>&1 endscript }     对我们来说，我们虚拟主机的日志和 nginx 的日志在相同的目录下，只是在下面添加了一个文件夹。 所以，我们就在上面添加文件夹就行。 归档测试 配置文件完成修改后，可以对配置进行测试： 运行命令： logrotate /etc/logrotate.d/nginx --debug 服务器上输出的内容为： root@ns564012:/etc/logrotate.d# logrotate /etc/logrotate.d/nginx --debug warning: logrotate in debug mode does nothing except printing debug messages! Consider using verbose mode (-v) instead if this is not what you want. reading config file /etc/logrotate.d/nginx Reading state from file: /var/lib/logrotate/status Allocating hash table for state file, size 64 entries Creating new state Creating new state Creating new state Creating new state Creating new state Creating new state Creating new state Creating new state Creating new state Creating new state Creating new state Creating new state Creating new state Creating new state Creating new state Creating new state Creating new state Creating new state Creating new state Creating new state Creating new state Creating new state Creating new state Creating new state Handling 1 logs rotating pattern: /var/log/nginx/*.log /var/log/nginx/src.isharkfly.com/*.log after 1 days (14 rotations) empty log files are not rotated, old logs are removed considering log /var/log/nginx/access.log Now: 2025-02-06 02:38 Last rotated at 2025-02-06 00:00 log does not need rotating (log has been rotated at 2025-02-06 00:00, which is less than a day ago) considering log /var/log/nginx/error.log Now: 2025-02-06 02:38 Last rotated at 2025-02-06 00:00…