إذا قمت بإجراء التحديثات من واجهة المستخدم، فستتلقى في النهاية رسالة تفيد بأنه يتعين عليك إجراء تحديث عبر سطر الأوامر. هذا لا يعتمد على Debian، بل على صورة Discourse الأساسية.
إعجابَين (2)
وهل مع طريقة الحاويتين لن يكون هناك زر تحديث لواجهة المستخدم الرسومية على الإطلاق، صحيح؟
يأتي تحديث واجهة المستخدم الرسومية من المكون الإضافي discourse_docker. إذا كان لديك هذا المكون الإضافي، فلديك تحديث واجهة المستخدم الرسومية.
عند اكتشاف ثغرات في أدوات معالجة الصور، فقد حدث استثناء للتعليمات البرمجية عن بُعد بالتأكيد في الماضي، مما يعني أنك على بعد تحميل صورة واحدة من نظام مخترق.
وضع Clear Linux المعيار لمدى سرعة الإقلاع على لينكس. إنه عمل رائع، أدعمه بكل إخلاص.
إعجاب واحد (1)
أوه، هذا يغير الأمور قليلاً إذن. لسبب ما كنت أعتقد أن محدث واجهة المستخدم الرسومية لن يعمل مع تثبيت غير قياسي من حاويتين. في هذه الحالة، طالما أن المسؤول يتمتع بالكفاءة التقنية، يبدو أنه لا توجد الكثير من السلبيات لتثبيت حاويتين. أريد بالتأكيد الحصول على تحديثات واجهة المستخدم الرسومية، على سبيل المثال إذا كنت أسافر بهاتفي فقط وخرج تحديث أمني كبير لـ Discourse، فيمكنني على الأقل تطبيقه دون الحاجة إلى الوصول عبر SSH.
إعجاب واحد (1)
هذا هو اعتقادي. أنت بحاجة أساسًا إلى الانتباه بما يكفي فقط لمعرفة متى يكون هناك ترقية لـ Postgres أو Redis تتطلب إعادة بناء حاوية البيانات. تحتاج أيضًا إلى معرفة كيفية تشغيل ./launcher bootstrap web_only & ./launcher destry web_only; ./launcher start web_only، ولكن هذا ليس بالأمر الصعب. يمكنك فقط تشغيل ./launcher rebuild web_only، ولكن هذا يؤدي إلى تعطيل الموقع أثناء إعادة بنائه.
إعجابَين (2)
فقط لكي نكون كاملين: واجهة المستخدم الرسومية على الويب تبنى عادةً بدون أي وقت تعطل؛ عملية التمهيد/التدمير/البدء لها وقت تعطل بسيط ولن أقوم بها إلا بشكل طبيعي مع صفحة صيانة مقدمة خارجيًا كما هو الحال مع nginx خارجي كما هو موثق هنا. ولكن هذه ممارسة جيدة على أي حال إذا كان ذلك فقط للحصول على عناوين IPv6 في الحاوية.
جيد جدًا ، شكرًا لك. ومع تثبيت حاويتين ، هل لا تزال تتلقى إشعارات لوحة تحكم Discourse عندما تحتاج الحاوية إلى إعادة بناء؟ وفي هذه الحالة ، هل يمكنني تحديد ما إذا كنت سأعيد بناء التطبيق فقط أم حاوية البيانات أيضًا؟
إعجاب واحد (1)
نعم. أراها الآن لأنني لم أطبق تحديث “تغير الإصدار فقط” 3.1.0.beta1. 
إعجاب واحد (1)
هذه حالة “لا بأس حتى لا يكون كذلك” - يصاب الناس بالذعر عندما يفشل التحديث في واجهة المستخدم ولا يعرفون تشغيل git pull; ./launcher rebuild app لتجاوز المشكلة. يحدث هذا في كل مرة يكون هناك تغيير يبطل تحديث واجهة المستخدم الرسومية، على ما أعتقد. لقد حدث مرة أخرى:
أشعر أن هذا الذعر يسلط الضوء على قيمة وجود آلية تحديث متسقة وطبيعية تتجنب هذه التجربة.
في الوقت نفسه، واجهت حالة نادرة أيضًا حيث يؤدي التمهيد إلى كسر النظام قيد التشغيل: التحديثات التي لا تتطلب وقت تعطل تقريبًا تنكسر من حين لآخر بهذه الطريقة، مرة أو مرتين في السنة ربما في المتوسط؟ لذا لا تتأخر بين التمهيد والتدمير/البدء.
يجب أن أقوم بتحديث النص لجعله واضحًا، لذا سأفعل ذلك بعد ذلك.
لم أقم بنشر LibreTranslate بعد، ولكني أفكر في القيام بذلك لجعل موقعي متاحًا دوليًا بشكل أكبر.
إذا نجحت في ذلك، أنوي تعديل ذلك في المنشور العلوي. 
إعجابَين (2)
الكثير من هذا يفوق فهمي، ولكني أريد أن أشكرك، لأن الإعدادات القليلة التي ذكرتها مع اقتراحات التعديل وشرح العواقب على كيفية إدارة المجتمع كانت ثمينة للغاية بالنسبة لي بالفعل!
4 إعجابات
سعدت بكونه مفيدًا حتى خارج جمهوري المستهدف. 
لقد استخدمته قبل أيام لإنشاء مثيل جديد لـ Discourse، وساعدني أيضًا، لأنني لا أتذكر كل هذا بنفسي. 
6 إعجابات
أعتقد أنه قد تكون هناك مشكلة في إعداد شفافية الصفحات الكبيرة (THP) في الويكي.
كنت أواجه مشكلات مع Redis على Ubuntu:
Your Redis network connection is performing extremely poorly. Last RTT readings were [96585, 101554, 97189, 99769, 94618], ideally these should be < 1000. Ensure Redis is running in the same AZ or dat
اعتقدت أن THP كانت معطلة بالفعل (من خلال متابعة الويكي) - ولكن اتضح أنها كانت لا تزال ممكّنة 
. تعطيل THP انتهى بحل المشكلة المذكورة أعلاه بالنسبة لي على ما أذكر (في أواخر العام الماضي).
Ubuntu 24.04 LTS (متابعة للويكي الحالي):
cat /sys/kernel/mm/transparent_hugepage/enabled
# المخرج:
# [always] madvise never
echo 'sys.kernel.mm.transparent_hugepage.enabled=never' > /etc/sysctl.d/10-huge-pages.conf
cat /etc/sysctl.d/10-huge-pages.conf
# المخرج:
# sys.kernel.mm.transparent_hugepage.enabled=never
sudo sysctl --system
# المخرج:
* Applying /usr/lib/sysctl.d/10-apparmor.conf ...
* Applying /etc/sysctl.d/10-bufferbloat.conf ...
* Applying /etc/sysctl.d/10-console-messages.conf ...
* Applying /etc/sysctl.d/10-huge-pages.conf ...
* Applying /etc/sysctl.d/10-ipv6-privacy.conf ...
* Applying /etc/sysctl.d/10-kernel-hardening.conf ...
* Applying /etc/sysctl.d/10-magic-sysrq.conf ...
* Applying /etc/sysctl.d/10-map-count.conf ...
* Applying /etc/sysctl.d/10-network-security.conf ...
* Applying /etc/sysctl.d/10-ptrace.conf ...
* Applying /etc/sysctl.d/10-zeropage.conf ...
* Applying /usr/lib/sysctl.d/50-pid-max.conf ...
* Applying /etc/sysctl.d/99-cloudimg-ipv6.conf ...
* Applying /usr/lib/sysctl.d/99-protect-links.conf ...
* Applying /etc/sysctl.d/99-sysctl.conf ...
* Applying /etc/sysctl.conf ...
kernel.apparmor_restrict_unprivileged_userns = 1
net.core.default_qdisc = fq_codel
kernel.printk = 4 4 1 7
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2
kernel.kptr_restrict = 1
kernel.sysrq = 176
vm.max_map_count = 1048576
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.rp_filter = 2
kernel.yama.ptrace_scope = 1
vm.mmap_min_addr = 65536
kernel.pid_max = 4194304
net.ipv6.conf.all.use_tempaddr = 0
net.ipv6.conf.default.use_tempaddr = 0
fs.protected_fifos = 1
fs.protected_hardlinks = 1
fs.protected_regular = 2
fs.protected_symlinks = 1
cat /sys/kernel/mm/transparent_hugepage/enabled
# المخرج:
# [always] madvise never
AlmaLinux 10 (متابعة للويكي الحالي):
cat /sys/kernel/mm/transparent_hugepage/enabled
# المخرج:
# [always] madvise never
echo 'sys.kernel.mm.transparent_hugepage.enabled=never' > /etc/sysctl.d/10-huge-pages.conf
cat /etc/sysctl.d/10-huge-pages.conf
# المخرج:
# sys.kernel.mm.transparent_hugepage.enabled=never
sudo sysctl --system
# المخرج:
* Applying /usr/lib/sysctl.d/10-default-yama-scope.conf ...
* Applying /etc/sysctl.d/10-huge-pages.conf ...
* Applying /usr/lib/sysctl.d/10-map-count.conf ...
* Applying /usr/lib/sysctl.d/50-coredump.conf ...
* Applying /usr/lib/sysctl.d/50-default.conf ...
* Applying /usr/lib/sysctl.d/50-libkcapi-optmem_max.conf ...
* Applying /usr/lib/sysctl.d/50-pid-max.conf ...
* Applying /usr/lib/sysctl.d/50-redhat.conf ...
* Applying /etc/sysctl.d/99-sysctl.conf ...
* Applying /etc/sysctl.conf ...
kernel.yama.ptrace_scope = 0
vm.max_map_count = 1048576
kernel.core_pattern = |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
kernel.core_pipe_limit = 16
fs.suid_dumpable = 2
kernel.sysrq = 16
kernel.core_uses_pid = 1
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.eth0.rp_filter = 2
net.ipv4.conf.eth1.rp_filter = 2
net.ipv4.conf.lo.rp_filter = 2
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.eth0.accept_source_route = 0
net.ipv4.conf.eth1.accept_source_route = 0
net.ipv4.conf.lo.accept_source_route = 0
net.ipv4.conf.default.promote_secondaries = 1
net.ipv4.conf.eth0.promote_secondaries = 1
net.ipv4.conf.eth1.promote_secondaries = 1
net.ipv4.conf.lo.promote_secondaries = 1
net.ipv4.ping_group_range = 0 2147483647
net.core.default_qdisc = fq_codel
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
fs.protected_regular = 1
fs.protected_fifos = 1
net.core.optmem_max = 81920
kernel.pid_max = 4194304
kernel.kptr_restrict = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.eth0.rp_filter = 1
net.ipv4.conf.eth1.rp_filter = 1
net.ipv4.conf.lo.rp_filter = 1
cat /sys/kernel/mm/transparent_hugepage/enabled
# المخرج:
# [always] madvise never
ربما يكون هذا مناسبًا للويكي؟ بدا أنه يعمل على Ubuntu 24.04 و AlmaLinux 10 من الاختبار الآن:
echo 'w /sys/kernel/mm/transparent_hugepage/enabled - - - - never' | sudo tee /etc/tmpfiles.d/10-huge-pages.conf
sudo systemd-tmpfiles --create /etc/tmpfiles.d/10-huge-pages.conf
للتأكيد:
cat /sys/kernel/mm/transparent_hugepage/enabled
المخرج المتوقع:
always madvise [never]
يسعدني سماع ذلك - إذا لم نكن نعرف ما إذا كان يساعد، فقد نكون فقط نقلد بعضنا البعض!
إعجاب واحد (1)
لا أعتقد أنه تم إهمال /etc/sysctl.d. هل يمكنك مراجعة الملفات الأخرى المدرجة هناك ومعرفة أي منها يحل محل `/etc/sysctl.d/10-huge-pages.conf؟ ربما أحد ملفات الأولوية 50 تلك؟
الحل الأفضل سيكون على الأرجح تغيير أولوية إعداد الصفحات الضخمة (huge-pages) للفوز. لكني لا أقوم بتشغيل أي من هذين الإصدارين حاليًا على أنظمتي.
تحقق أيضًا مما إذا كانت خدمة tuned تحل محل الإعداد.
إعجاب واحد (1)
لم تكن لدي مشكلة سوى في تطبيق إعدادات THP، حيث تم تطبيق vm.overcommit.memory كما هو متوقع عبر /etc/sysctl.d. تم ملاحظة ذلك وحله على خادم في أواخر العام الماضي. لذلك، حاولت التحقق عبر عدد قليل من خوادم VPS الصغيرة (micro VPSs) بالأمس.
جربت للتو هذا على خادم AlmaLinux 9 micro VPS جديد، في محاولة لمعرفة ما إذا كانت أي من ملفات .conf الافتراضية تؤثر على إعداد THP:
echo always | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
# المخرج:
# always
cat /sys/kernel/mm/transparent_hugepage/enabled
# المخرج:
# [always] madvise never
sysctl --system
# المخرج:
* Applying /usr/lib/sysctl.d/10-default-yama-scope.conf ...
* Applying /usr/lib/sysctl.d/50-coredump.conf ...
* Applying /usr/lib/sysctl.d/50-default.conf ...
* Applying /usr/lib/sysctl.d/50-libkcapi-optmem_max.conf ...
* Applying /usr/lib/sysctl.d/50-pid-max.conf ...
* Applying /usr/lib/sysctl.d/50-redhat.conf ...
* Applying /etc/sysctl.d/99-sysctl.conf ...
* Applying /etc/sysctl.conf ...
kernel.yama.ptrace_scope = 0
kernel.core_pattern = |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
kernel.core_pipe_limit = 16
fs.suid_dumpable = 2
kernel.sysrq = 16
kernel.core_uses_pid = 1
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.eth0.rp_filter = 2
net.ipv4.conf.eth1.rp_filter = 2
net.ipv4.conf.lo.rp_filter = 2
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.eth0.accept_source_route = 0
net.ipv4.conf.eth1.accept_source_route = 0
net.ipv4.conf.lo.accept_source_route = 0
net.ipv4.conf.default.promote_secondaries = 1
net.ipv4.conf.eth0.promote_secondaries = 1
net.ipv4.conf.eth1.promote_secondaries = 1
net.ipv4.conf.lo.promote_secondaries = 1
net.ipv4.ping_group_range = 0 2147483647
net.core.default_qdisc = fq_codel
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
fs.protected_regular = 1
fs.protected_fifos = 1
net.core.optmem_max = 81920
kernel.pid_max = 4194304
kernel.kptr_restrict = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.eth0.rp_filter = 1
net.ipv4.conf.eth1.rp_filter = 1
net.ipv4.conf.lo.rp_filter = 1
cat /sys/kernel/mm/transparent_hugepage/enabled
# المخرج:
# [always] madvise never
echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
# المخرج:
# never
cat /sys/kernel/mm/transparent_hugepage/enabled
# المخرج:
# always madvise [never]
sysctl --system
# المخرج:
* Applying /usr/lib/sysctl.d/10-default-yama-scope.conf ...
* Applying /usr/lib/sysctl.d/50-coredump.conf ...
* Applying /usr/lib/sysctl.d/50-default.conf ...
* Applying /usr/lib/sysctl.d/50-libkcapi-optmem_max.conf ...
* Applying /usr/lib/sysctl.d/50-pid-max.conf ...
* Applying /usr/lib/sysctl.d/50-redhat.conf ...
* Applying /etc/sysctl.d/99-sysctl.conf ...
* Applying /etc/sysctl.conf ...
kernel.yama.ptrace_scope = 0
kernel.core_pattern = |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
kernel.core_pipe_limit = 16
fs.suid_dumpable = 2
kernel.sysrq = 16
kernel.core_uses_pid = 1
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.eth0.rp_filter = 2
net.ipv4.conf.eth1.rp_filter = 2
net.ipv4.conf.lo.rp_filter = 2
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.eth0.accept_source_route = 0
net.ipv4.conf.eth1.accept_source_route = 0
net.ipv4.conf.lo.accept_source_route = 0
net.ipv4.conf.default.promote_secondaries = 1
net.ipv4.conf.eth0.promote_secondaries = 1
net.ipv4.conf.eth1.promote_secondaries = 1
net.ipv4.conf.lo.promote_secondaries = 1
net.ipv4.ping_group_range = 0 2147483647
net.core.default_qdisc = fq_codel
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
fs.protected_regular = 1
fs.protected_fifos = 1
net.core.optmem_max = 81920
kernel.pid_max = 4194304
kernel.kptr_restrict = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.eth0.rp_filter = 1
net.ipv4.conf.eth1.rp_filter = 1
net.ipv4.conf.lo.rp_filter = 1
cat /sys/kernel/mm/transparent_hugepage/enabled
# المخرج:
# always madvise [never]
لهذا السبب أطلب منك مراجعة الملفات الفعلية للعثور على ما يحل محلها، حتى أتمكن من إجراء تغيير مستنير على الأولوية التي أوصي بها للتجاوز.
إعجاب واحد (1)
فهمي الحالي (المحدود) هو أن الأوامر/المخرجات من منشوري السابق تشير إلى عدم وجود تجاوز.
بالنظر إلى الملفات الموجودة في نسخة AlmaLinux 9 جديدة:
كانت هذه النتائج فارغة:
grep -r "transparent_hugepage" /usr/lib/sysctl.d/ /etc/sysctl.d/ /etc/sysctl.conf
grep -r "transparent" /usr/lib/sysctl.d/ /etc/sysctl.d/ /etc/sysctl.conf
grep -r "huge" /usr/lib/sysctl.d/ /etc/sysctl.d/ /etc/sysctl.conf
grep -r "page" /usr/lib/sysctl.d/ /etc/sysctl.d/ /etc/sysctl.conf
القيم الافتراضية في ملفات الإعدادات:
/usr/lib/sysctl.d/50-redhat.conf:kernel.kptr_restrict = 1
/usr/lib/sysctl.d/50-redhat.conf:net.ipv4.conf.default.rp_filter = 1
/usr/lib/sysctl.d/50-redhat.conf:net.ipv4.conf.*.rp_filter = 1
/usr/lib/sysctl.d/50-redhat.conf:-net.ipv4.conf.all.rp_filter
/usr/lib/sysctl.d/10-default-yama-scope.conf:kernel.yama.ptrace_scope = 0
/usr/lib/sysctl.d/50-libkcapi-optmem_max.conf:net.core.optmem_max = 81920
/usr/lib/sysctl.d/50-coredump.conf:kernel.core_pattern=|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
/usr/lib/sysctl.d/50-coredump.conf:kernel.core_pipe_limit=16
/usr/lib/sysctl.d/50-coredump.conf:fs.suid_dumpable=2
/usr/lib/sysctl.d/50-default.conf:kernel.sysrq = 16
/usr/lib/sysctl.d/50-default.conf:kernel.core_uses_pid = 1
/usr/lib/sysctl.d/50-default.conf:net.ipv4.conf.default.rp_filter = 2
/usr/lib/sysctl.d/50-default.conf:net.ipv4.conf.*.rp_filter = 2
/usr/lib/sysctl.d/50-default.conf:-net.ipv4.conf.all.rp_filter
/usr/lib/sysctl.d/50-default.conf:net.ipv4.conf.default.accept_source_route = 0
/usr/lib/sysctl.d/50-default.conf:net.ipv4.conf.*.accept_source_route = 0
/usr/lib/sysctl.d/50-default.conf:-net.ipv4.conf.all.accept_source_route
/usr/lib/sysctl.d/50-default.conf:net.ipv4.conf.default.promote_secondaries = 1
/usr/lib/sysctl.d/50-default.conf:net.ipv4.conf.*.promote_secondaries = 1
/usr/lib/sysctl.d/50-default.conf:-net.ipv4.conf.all.promote_secondaries
/usr/lib/sysctl.d/50-default.conf:-net.ipv4.ping_group_range = 0 2147483647
/usr/lib/sysctl.d/50-default.conf:-net.core.default_qdisc = fq_codel
/usr/lib/sysctl.d/50-default.conf:fs.protected_hardlinks = 1
/usr/lib/sysctl.d/50-default.conf:fs.protected_symlinks = 1
/usr/lib/sysctl.d/50-default.conf:fs.protected_regular = 1
/usr/lib/sysctl.d/50-default.conf:fs.protected_fifos = 1
/usr/lib/sysctl.d/50-pid-max.conf:kernel.pid_max = 4194304
أنا أشغل AlmaLinux 9 لخوادم Discourse الخاصة بي، والإعداد الذي قدمته نجح في تعطيل THP على جميعها. إذا كان تعطيل THP عبر sysctl.d لا يعمل عندما لا تكون هناك تجاوزات مطبقة، و tuned لا يتجاوز ذلك، فأعتقد أن هذا خطأ.
اعتقدت أنك كنت تقول إنه لم يعد يعمل على AlmaLinux 10، ولهذا السبب كنت أسأل ما الذي يمنعه من التطبيق هناك.