
سالها این باور رایج بود که یک NAS بدون سیستمعامل اختصاصی NAS کار نمیکند. اما یک کاربر پس از تجربه مصرف بالای رم در TrueNAS 25.10، تصمیم گرفت مسیر متفاوتی را امتحان کند: نصب دبیان ۱۳ خالص و افزودن Cockpit بهعنوان داشبورد تحت وب مدیریت سرور لینوکس. نتیجه پس از سه هفته، سروری سبکتر و در همان حال توانمندتر بوده است.
چرا TrueNAS 25.10 رم زیادی میخواست؟
TrueNAS بهطور تصادفی سنگین نیست. راهنمای سختافزاری خود این سیستمعامل، ۸ گیگابایت رم را بهعنوان حداقل پایه پیشنهاد میکند، چون میانافزار (Middleware)، رابط وب، سیستم اپلیکیشنها و ZFS همگی از یک استخر حافظه مشترک استفاده میکنند. روی یک دسکتاپ بازسازیشده با دو هارد ۴ ترابایتی WD Red Plus در حالت آینه (Mirror)، همین موضوع فضای کمی برای کش خواندن ZFS باقی میگذاشت؛ همان بخشی که سرعت احساسشده NAS را میسازد.
مشکل دیگر apt بود. TrueNAS بر پایه دبیان ساخته شده، اما اگر بخواهید از شل یک بسته نصب کنید، با پاسخ صریح «Package management tools are disabled on TrueNAS appliances» روبهرو میشوید. کاربر فقط میخواست restic را برای پشتیبانگیری خارج از سایت نصب کند، اما راهحل همیشگی، بستهبندی آن در قالب یک اپلیکیشن بود.
مهاجرت به دبیان ۱۳ و Cockpit
ترسناکترین بخش مهاجرت، تنها یک دستور بود. کاربر ابتدا فایل تنظیمات TrueNAS را ذخیره کرد، استخر ZFS را export کرد و سپس دبیان ۱۳ را بدون دسکتاپ، فقط با SSH و ابزارهای استاندارد سیستم نصب کرد. ZFS در مخزن contrib دبیان قرار دارد و trixie-backports در حال حاضر OpenZFS 2.4.3 را ارائه میدهد که از نسخه 2.3.4 همراه TrueNAS 25.10 جدیدتر است. پس از اجرای zpool import tank، حدود ۳.۶ ترابایت عکس، فایل کاری و ISOهای لینوکسی دقیقاً همانجایی که قبلاً بودند ظاهر شدند.
نکته مهم این است که پیش از پاککردن هر چیزی، استخر را از TrueNAS export کنید و یک نسخه از فایل تنظیمات را بیرون از سرور نگه دارید. اگر مهاجرت درست پیش نرفت، میتوانید TrueNAS را دوباره نصب کنید و همهچیز را برگردانید.
برای دریافت جدیدترین نسخه Cockpit، آن را از backports دبیان نصب کنید: sudo apt install -t trixie-backports cockpit cockpit-podman cockpit-machines. داشبورد سپس روی پورت ۹۰۹۰ سرور در دسترس قرار میگیرد.
خود Cockpit با یک خط نصب میشود و افزونهها بخش NAS را انجام میدهند. افزونه cockpit-file-sharing از 45Drives اشتراکهای Samba و NFS را مدیریت میکند و iSCSI و S3 را هم پوشش میدهد. cockpit-podman کانتینرها را اجرا میکند و cockpit-machines ماشینهای مجازی را مدیریت میکند. بازسازی چهار اشتراک SMB و یک export NFS حدود ۱۵ دقیقه طول کشید.
مقایسه مصرف رم و سرعت بوت
- رم سیستم در حالت بیکاری بدون اپلیکیشن: TrueNAS 25.10 حدود ۳.۲ گیگابایت، دبیان ۱۳ بههمراه Cockpit حدود ۶۴۰ مگابایت.
- بوت تا آنلاینشدن اشتراکهای SMB: TrueNAS حدود ۲ دقیقه و ۴۱ ثانیه، دبیان و Cockpit حدود ۵۲ ثانیه.
- اجرای روزمره: TrueNAS با ۲ اپلیکیشن، دبیان و Cockpit با ۳ کانتینر و ۱ ماشین مجازی.
- نصب هر بسته دبیان: در TrueNAS خیر، در دبیان بله.
Socket activation و آزادسازی رم
ترفند اصلی این است که Cockpit بهسختی در حال اجرا میماند. این داشبورد از طریق فعالسازی سوکت (Socket Activation) و بر اساس تقاضا شروع به کار میکند؛ بنابراین وقتی هیچکس وارد داشبورد نشده، عملاً در حال اجرا نیست. هر چیزی که نشان میدهد، همان سیستم واقعی است: همان سرویسها، لاگها، دیسکها و کانتینرهایی که از ترمینال هم قابل دسترسیاند. با بستن تب، سرور دوباره به یک جعبه دبیان آرام تبدیل میشود.
رم آزادشده بلافاصله به کار گرفته شد. Jellyfin، Syncthing و Uptime Kuma اکنون بهصورت کانتینرهای Podman اجرا میشوند و یک ماشین مجازی ۲ گیگابایتی Home Assistant در cockpit-machines زندگی میکند. در TrueNAS، اجرای همین ماشین مجازی در کنار دو اپلیکیشن، سیستم را به سمت swap میبرد. اما در دبیان، ZFS حتی با اجرای همه اینها حدود ۳.۴ گیگابایت برای کش خود در اختیار دارد.
حتی کارهای خستهکننده هم به مرورگر منتقل شدهاند. از Cockpit 356 به بعد، صفحه Services میتواند تایمرهای systemd بسازد که دستورهای شل را اجرا میکنند. به این ترتیب، snapshot شبانه و پشتیبانگیری restic روی سرور یک دوست، دو تایمر قابل ویرایش بدون بازکردن ترمینال هستند.
تنظیمات اشتراکگذاری و باگ Time Machine
دو روز پس از مهاجرت، MacBook Air M2 دیگر اشتراک Time Machine را نمیدید. TrueNAS بهطور خاموش تنظیمات اضافی اپل را انجام میداد، اما Samba خالص این کار را نمیکند. اشتراک به vfs objects = fruit streams_xattr و fruit:time machine = yes نیاز داشت و سرور هم برای پیدا شدن در شبکه به avahi-daemon احتیاج داشت. cockpit-file-sharing یک جعبه تنظیمات پیشرفته دقیقاً برای همین کار دارد، بنابراین پس از دانستن راهحل، رفع مشکل پنج دقیقه طول کشید؛ اما کشف آن یک شب کامل وقت گرفت.
اینجاست که نکته واقعی روشن میشود. TrueNAS ظرافتهایی دارد که تا وقتی از دست نروند، به چشم نمیآیند؛ مانند وظایف snapshot، replication و هشدارهایی که پیش از خرابشدن یک درایو ایمیل میفرستند. دبیان بهصورت پیشفرض یک scrub ماهانه ZFS دارد، اما هشدارها بر عهده خود کاربر است. کاربر با راهاندازی smartd و daemon رویداد ZFS برای خود ایمیل تنظیم کرد و این کار جواب داد، ولی دیگر کسی دست او را نمیگیرد. اگر سرور ساعت ۲ بامداد خراب شود، تیم پشتیبانی خودش است.
جمعبندی: دبیان خالص برای سرور خانگی کوچک
اگر یک appliance میخواهید، TrueNAS همچنان انتخاب درستی است و حتی برای آزمایشگاه خانگی مبتنی بر ماشین مجازی، گزینههای بهتری مانند Proxmox وجود دارد. لینوکس خالص برای جعبه کوچکی مناسب است که کمی از همهکار را انجام میدهد و برای این کاربر، معامله در همان هفته اول به سود تبدیل شد.
او انتظار داشت بیشتر از این دلتنگ TrueNAS شود. عدد ۳.۲ گیگابایت در حالت بیکاری که همهچیز از آن شروع شد، اکنون ۶۴۰ مگابایت است و جعبهای که تقریباً کنار گذاشته شده بود، بیش از همیشه کار انجام میدهد. پیمایش کتابخانه عکس از گوشی هم سریعتر احساس میشود، چون ZFS بالاخره فضای کافی برای کش دارد. اگر با ترمینال راحت هستید و NAS شما روی سختافزار متوسط اجرا میشود، دبیان خالص بههمراه Cockpit ارزش یک آخر هفته را دارد؛ فقط پیش از آنکه مک متوجه شود، Time Machine را تنظیم کنید.