پست‌ها

lnav ابزاری بسیار کاربردی برای پیمایش لاگ ها در لینوکس و البته مک

تصویر
خب گرمی هوا و تعطیلی فرصتی شد برای نوشتن درباره lnav   طبق تعریف رسمی lanv خودش رو یک نمایش دهنده لاگ فایل که UI اون بر پایه ncurses(رابط کاربری مبتنی بر متن مثل norton commander ) هست میدونه و اما قابلیت ها ادغام و نمایش چندین لاگ فایل در یک پنجره خیلی پیش میاد برای ریشه یابی یک مشکل مجبور باشیم چندین لاگ رو همزمان بررسی کنیم.وقتی چندین فایل رو با هم باز میکنیم براساس timestamp خطوط لاگ رو نمایش میده و به کمک رنگ های متفاوت هر خط رو متمایز میکنه lnav /var/log/messages /var/log/secure تشخیص خودکار فرمت لاگ به صورت داخلی و پیش فرض lanv از لیست بلند بالایی از فرمت ها پشتیبانی میکنه مثلا اکثر وب سرور ها مثل nginx اگرهم فرمت مدنظر شما داخل این لیست نیست امکان تعریف فرمت شخصی رو هم دارید. فیلترکردن لاگ های حجیم قبل از بازکردن معمولا پیش میاد که با یک فایل چند گیگ ی کارداریم و فقط میخواهیم مثلا سطح  WARN ها رو ببینیم . در مثال زیر اگر دقت کنید خروجی شامل کلی لاگ DEBUG هست ولی با کمک فیلتر رسیدیم به چندین خط و البته میتونیم چندین نوع فیلتر دیگه هم داشته باشیم مثلا regex و ... مشتری عزیرمون ق

ساختن ایمیج های داکری به کمک BuildKit - بخش دوم

تصویر
 خب با یک فاصله طولانی از بخش اول میرسیم به بخش دوم ساختن ایمیج های داکری به کمک BuildKit در این قسمت قراره درباره امنیت و در واقع امن کردن داکرفایل یا ایمج هامون صحبت کنیم.وقتی که نیاز داریم مثلا به یک مخزن خصوصی وصل بشیم یا یک فایل رو از یک سایت خاص💪 مثلا sonaops.ir دانلود کنیم یا ... و مجبوریم یک سری اطلاعات شخصی (نام کاربری رمز عبور و...) رو وارد کنیم در صورت رعایت نکردن یکسری اصول امنیتی ایمیج ما مستعد خرابکاری میشه و...  تا قبل از BuildKit یک روش استفاده از ARG داخل داکر فایل و مقداردهی اون هنگام build به کمک build-arg بود (و هست) مشکل این روش اینه که از طریق خواندن تاریخچه ساخت یک ایمیج این اطلاعات درز میکنه و البته از اون بدتر اگه این اطلاعات رو به نوعی داخل ایمیج ذخیره کرده باشید به راحتی قابل دسترسی هست (حتی اگه تو یک مرحله اونو پاک کرده باشید) سرچ زیر تو گوگل احتمالا نتیجه های جالبی رو برگردونه inurl:Dockerfile site:github.com intext:"ARG password" OR intext:"ARG secret" OR intext:"ARG pass" و در ادامه در صورت دستیابی به ایمیج مربوطه docker h

ساختن ایمیج های داکری به کمک BuildKit - بخش اول

تصویر
خب چند سالی هست که داکر راه خوبان رو داره میره و با تعریف پروژه موبی قدم بزرگی تو پشرفت کانتینر سازی (که البته به اشتباه معمولا میگیم داکر سازی و چه اشتباه خوبی ) برداشته.     یکی از زیر پروژه های موبی که اتفاقا بحث اصلی این پست و پست های آتی هست BuildKit نام داره که در واقع ابزاری برای ساخت ایمیج هست که در ابتدا به صورت مجزا قابل استفاده بود(و البته هنوزم هست) و از داکر ورژن 18.09 به صورت داخلی به داکر اضافه شده.   برای استفاده از این بیلدر یا میتونیم متغییر محیطی بنام DOCKER_BUILDKIT رو مقدار دهی کنیم و یا daemon.json رو ویرایش کنیم  export DOCKER_BUILDKIT=1 OR  vi /etc/docker/daemon.json   { "features" : { "buildkit" : true } }  systemctl daemon-reload systemctl restart docker       بعد از تغییر بیلدر پیش فرض داکر خروجی بیلدر هنگام ساخت ایمیج به شکل زیر میشه   نکته : من برای راحتی برای دستور docker دگرنام( alias ) dcr رو انتخاب کردم. در این پست و پست های آتی به برسی قابلیت های مهم BuildKit میپردازیم   پردازش موازی شاید یکی از مهمترین قابلیت های BuildKit پ

برسی استاندارد های Branching Model در گیت

تصویر
Git flow   به طور خلاصه  در این استاندارد قابلیت های جدید تحت شاخه های feature در شاخه develop ادغام میشوند.  در زمان رسیدن به زمان انتشار نسخه (چه از بعد تعداد قابلیت جدید یا زمان ) شاخه release ی از شاخه develop شده و اماده تست uat میشود.  شاخه master همیشه شامل نسخه لایو میباشد.  درصورت وجود باگ در نسخه لایو شاخه hotfix ی از master ساخته شده و در نهایت در شاخه master و develop ادغام میشود.      مزایا     اطمینان از تمیز بودن هر شاخه در طول عمر هر پروژه به واسطه تفکیک زیاد شاخه ها از هم نام گذاری قابل فهم شاخه ها پشتیبانی قوی در ابزارهای git  مناسب برای زمانی که میخواهیم چندین ورژن از محصول در محیط لایو یا عملیاتی داشته باشیم   معایب   تاریخچه کامیت های گیت خوانا نمیباشد جداسازی شاخه master و develop بنوعی اضافه تلقی میشود و باعث سخت شدن پروسه ها ci/cd میشود برای داشتن تنها یک نسخه در محیط لایو یا عملیات توصیه نمیشود   Github flow    ساده ترین استاندارد میباشد و به طور خلاصه در این استاندارد قابلیت های جدید تحت شاخه های feature در شاخه develop ادغام میشوند.   مزایا   مناسب برای پروس

یک اسفند دو صفر شروعی دوباره

خب مثل یک چشم بهم زدن ۱۰ سال گذشت ۱۰ فروردین سال ۱۳۹۱ آخرین پست من در این وبلاگ که از SQL server 2012 نوشتم...  زندگی شغلی من هم تو این مدت دستخوش تغییر شد و از دنیای مایکروسافت به دنیای لینوکس ورود کردم از برنامه نویسی c# و سروکله زدن با SQL server تا کلی تجربه و چالش جدید با لینوکس و اوراکل و رسیدن به DevOps.  از سال ۸۷ که زندگی شغلی من تو حوزه IT شروع شد (بعنوان پشتیبان سیستم) همیشه با کارهای تکراری و به اصطلاح گل :) مشکل داشتم و سعی میکردم تا حد ممکن تسک های که سمت من میومد رو خودکار کنم با ابزارهای مثل autoit کار میکردم اسکریپت می‌نوشتم و...  من عاشق کامپیوتر و طبعا کارهام بودم ولی DevOps یک خون تازه ی تو زندگی شغلی من به جریآن انداخت و به نوعی نیمه گمشده من بود. تصمیم گرفتم حال خوبم مخصوصا تو چند سال اخیر رو که به واسطه DevOps بوده با نوشتن بهتر کنم و البته تجربیات م رو با شما به اشتراک بگذارم و هم یاد بدم و هم یاد بگیرم. برای ادامه تصمیم گرفتم اسم وبلاگ رو عوض کنم به SonaOps و اما SonaOps یعنی چه ؟ تکلیف قسمت دوم که مشخصه اسم وبلاگ منم میشه یکی از چند ده نامی که از DevOps اقت

ويژگيهاي جديد SQL Server 2012

تصویر
مدتي از انتشار نسخه 2012 ه SQL Server با كد نام Denali ميگذره در اين پست قصد دارم چنديدن ويژگي جديد اين نسخه رو معرفي كنم.ضمنا دريافت اين نسخه و تبديل اون به نسخه نهايي رو از اين پست ميتونيد پيگيري كنيد. AlwaysOn : يكي از مهمترين ويژگيها در SQL Server 2012 در بحث High Availability يا در دسترس بودن هست و در واقع تكميل كننده Database Mirroring در نسخه هاي قبلي ميباشد.در Mirroring ما به صورت تك تك ديتابيس هامون رو ميرور ميكنيم ولي در AlwaysOn اينكار به صورت گروهي انجام ميشه يعني چندين ديتابيس و همچنيا ميتونيم دو روش همزمان (Synchronous) و غير همزمان (Asynchronous) رو با هم تركيب كنيم.بر خلاف ميرورينگ ديتابيس ما به صورت فقط خواندني قابل كوئري گرفتنه و حتي بكاپ گرفتن. نكته:در نسخه هاي قبلي با گرفتن Snapshot از ديتابيس Mirror ميتوان به صورت فقط خواندني از ديتابيس استفاده كرد و … پشتيباني از Windows Server Core : يادمه دوره كارداني استاد شبكه اي داشتيم كه لينوكس رو بهمون به صورت Command ي درس ميداد كلي از دستش شاكي بوديم كه چرا GUI نه ... نسخه 2012 ي SQL Server قابل نصب ر

جلوگیری از حملات دستکاری آدرس در ASP.NET MVC‌

یکی از ویژگی های ASP.NET MVC نحوه آدرس دهی صفحات و منابع یا همون URL هست که تر و تمیزه و از سوی کاربر قابل فهمه یا به عبارتی SEO Friendly URLs ه.مثلا اگه شما Controller ی بنام Profile داشته باشید که یکی از Action Method های اون Index باشه موقع کار با این Controller آدرس های ارسالی به صورت زیر میشن. www.dotnetdev.info/Profile/2 همه چی آرومه! تا اینکه یه کاربر کنجکاو اون 2 ی آخر URl رو میکنه 3 و… اینجاس که وب سایت شما در مقابل «حمله دستکاری آدرس» یا URL Manipulation Attack یا Parameter Manipulation ضعف داره. و اماچه باید کرد؟ برای جلوگیری از این حمله روش های مختلفی موجود که بعضیاش شکننده و آماتور و بعضیاش حرفه ای ن و البته راه حل نهایی. همونطور که گفتم روش های متفاوتی موجوده که بر میگرده به سناریوی ما که مهمترینش وجود رابطه بین درخواست ارسالی از سمت کاربر و هویت اون کاربره مثلا تو مثال بالا حتما رابطه یک به یک بین پروفایل و کاربر موجوده و یا مثلا یک سیستم اتوماسیون اداری رو در نظر بگیرید بین درخواست های ایجاد شده در سیستم و کاربر رابطه موجوده.خب حالا این رابطه ها کجا