תחומים - פורום חרדי מקצועי

@cfopuser כתב בעמוד Actions בGitHub נחסם בנטפרי?:

@מעלה-ומוריד השירות הזה מעולם היה בעייתי לסינונים,
מסתמא בזמננו עם ai שמדריך כול אחד נטפרי החלו יותר להחמיר בנידון.

הם לא חסמו את השירות אלא רק דרך אחת לראות את הלוגים.

@קומפיונט כתב בעמוד Actions בGitHub נחסם בנטפרי?:

גם אני נתקלתי בזה אתמול

@ע-ה-דכו-ע כתב בעמוד Actions בGitHub נחסם בנטפרי?:

אפשר להשתמש גם בתוסף github actions הרשמי לVS CODE לצפייה בהתקדמות ובלוגים

אפשר לראות שם רק את ההתקדמות של ה steps אבל לא רואים את הלוגים.
ב - GitHub CLI אפשר לראות את הלוגים אחרי הכישלון. (לא בזמן אמת כמו בדף שנחסם)

בתוסף github actions גם כן אפשר לראות את הלוגים לאחר הסיום של הריצה, בדיוק כמו בcli.

@מעלה-ומוריד כתב בעמוד Actions בGitHub נחסם בנטפרי?:

מה עושים? אני צריך לראות לוגים של כישלון הוורקפלואו
עריכה: כמובן משתמשים בGitHub CLI ומודים להקב"ה ברוך שמסר עולמו לשומרים

אפשר להשתמש גם בתוסף github actions הרשמי לVS CODE לצפייה בהתקדמות ובלוגים

@Jabberwock כתב בכיצד לתקן דליפת זיכרון בשרת?:

על פניו, ולפי המידע שנתת, אין שום בעיה בזיכרון. האם כאשר חווית איטיות, הופיע ב-HTOP שימוש בזיכרון קובץ החלפה (SWAP)? אם לא, ייתכן והיה עומס על השרת בו מאוחסן ה-VPS.

כן, הקובץ SWAP בא לידי שימוש בזמן העומס, והRAM היה בשימוש של 100%

בעיה ודאי שיש, השאלה במה

@Jabberwock כתב בכיצד לתקן דליפת זיכרון בשרת?:

לא בדיוק, נתפסת הקצאה לנפח.
במקום לבצע אתחול לכל השרת, הייתי מנסה לעשות אתחול לתהליך שאני חושד בו.
כלומר, אם הוא מקצה זיכרון ולא עושה בו שימוש, ברגע שהתהליך יושמד, מערכת ההפעלה תבטל גם את ההקצאות שלו. וכך תוכל להבין מה מקור הדליפה.

הפעלה מחדש של הקונטיינר דוקר כאשר התוכנות הללו עדיין עבדו על הדוקר לא עזרה

@Jabberwock כתב בכיצד לתקן דליפת זיכרון בשרת?:

וגם, תוכל להריץ cat /proc/meminfo

כרגע הזיכרון במצב מצויין פחות או יותר אחרי הפעלה מחדש, אבל הרצתי את זה בעבר עם סינון, וזה היה הפלט:

➜  ~ cat /proc/meminfo | grep -E "MemTotal|MemAvailable|Slab|SUnreclaim|Shmem|VmallocUsed"
MemTotal:        8132124 kB
MemAvailable:    1031840 kB
Shmem:              1268 kB
Slab:             175276 kB
SUnreclaim:       145920 kB
VmallocUsed:       21232 kB
ShmemHugePages:        0 kB
ShmemPmdMapped:        0 kB

כרגע זה הפלט:

➜  ~ cat /proc/meminfo
MemTotal:        8132128 kB
MemFree:         5281020 kB
MemAvailable:    5787144 kB
Buffers:           23760 kB
Cached:           612268 kB
SwapCached:            0 kB
Active:          1628768 kB
Inactive:         242760 kB
Active(anon):    1245380 kB
Inactive(anon):        0 kB
Active(file):     383388 kB
Inactive(file):   242760 kB
Unevictable:       27444 kB
Mlocked:           27444 kB
SwapTotal:       4194300 kB
SwapFree:        4194300 kB
Zswap:                 0 kB
Zswapped:              0 kB
Dirty:                36 kB
Writeback:             0 kB
AnonPages:       1262968 kB
Mapped:           339568 kB
Shmem:              1128 kB
KReclaimable:     185396 kB
Slab:             294532 kB
SReclaimable:     185396 kB
SUnreclaim:       109136 kB
KernelStack:        3584 kB
PageTables:         8328 kB
SecPageTables:         0 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     8260364 kB
Committed_AS:    2428964 kB
VmallocTotal:   34359738367 kB
VmallocUsed:       20436 kB
VmallocChunk:          0 kB
Percpu:             2096 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
ShmemPmdMapped:        0 kB
FileHugePages:         0 kB
FilePmdMapped:         0 kB
Unaccepted:            0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
Hugetlb:               0 kB
DirectMap4k:      169832 kB
DirectMap2M:     8218624 kB

@Jabberwock כתב בכיצד לתקן דליפת זיכרון בשרת?:

שים לב שה-Virtual Memory שלך גדל בתהליך שנקרא "the-channel-bin".
בין צילומי המסך של האחרי והלפני שהעלאת יש גדילה של 1.71GB בסה"כ.
התהליך המדובר גדל רק ב-524MB. כלומר יש עוד דליפה ממקור אחר, או שיש תהליכים חדשים חבואים?

ברור שיש דליפה ממקום אחר, על זה אני שואל מהיכן הדליפה. לא ניכר תהליכים חדשים, והערך שרשום בעמודה של VIRT בכלל לא קשור לתפיסת זיכרון בשרת, כיוון שהוא לא תופס זיכרון בפועל.

@Jabberwock כתב בכיצד לתקן דליפת זיכרון בשרת?:

בהתחלה ציינת שיש גם מסד נתונים, איפה הוא? הוא לא ברשימה של htop.

זה redis והוא השלישי ברשימה.

@Jabberwock כתב בכיצד לתקן דליפת זיכרון בשרת?:

תבדוק אצלך אולי זה מה שקורה.

כנ"ל התפיסת זיכרון הזו לא אמורה להיות באמת תפוסה.

@חגי כתב בכיצד לתקן דליפת זיכרון בשרת?:

אתה יכול לשתף פה את הפלט של free -m?

➜  ~ free -m
               total        used        free      shared  buff/cache   available
Mem:            7941        6691         897           1         736        1250
Swap:           4095           0        4095

@חגי כתב בכיצד לתקן דליפת זיכרון בשרת?:

אני פשוט חושד שהבעיה שלך היא זו - https://www.linuxatemyram.com/

אני גם בדקתי את זה דבר ראשון, אבל כמו שאתה רואה הזיכרון תפוס בהחלט, וגם מפריע לשרת לפעול כאשר הוא עמוס מידי.

@dovid כתב בכיצד לתקן דליפת זיכרון בשרת?:

זה קשקוש צורכת מינימום משאבים! אם היא גורמת לקרנל לגדול איך אתה יכול לדעת?

זה קרה עוד לפני שהיא הותקנה, בנוסף היא אותו תוכנה כמו התוכנה הגדולה, שהייתה מותקנת כבר מזמן ולא עשה בעיות אף פעם.

@dovid כתב בכיצד לתקן דליפת זיכרון בשרת?:

אגב הCaddy אמור להיות כמה מגה בודדים, אז אתה יכול להתמקד בו.

לא כשהוא צריך לטפל בSSE קבוע לאלפי משתמשים בו זמנית, הצריכה שרשומה עליו נורמלית לגמרי, ואין שום בעיה בלוגים.

לפי איך שזה נראה בלוגים של fail2ban אני לא תחת מתקפה (למרות שלפני שהתקנתי אותו והחלפתי פורט לSSH כנראה כן היה איזו שהיא מתקפה, אבל זה היה מזמן).

@dovid כתב בכיצד לתקן דליפת זיכרון בשרת?:

יש חומת אש שאתה יכול להפעיל לפני השרת?

השירות הזה נוסף בקונטאבו בדיוק בחודש האחרון, אולי אני באמת אנסה.

@ivrtikshoret כתב בכיצד לתקן דליפת זיכרון בשרת?:

פה לא רואים שזה מלא, אתה צריך לנסות לעשות צילו"מ כאשר זה מגיע ליותר קרוב ל 100 אחוז

זה באמת כרגע לא מלא, אבל זה עדיין כפול 2 מהצריכה הבסיסית של השרת כאשר כל התוכנות פועלות, עכשיו זה כבר עלה עוד קצת

@dovid כתב בכיצד לתקן דליפת זיכרון בשרת?:

אין פה תוכנה יחידה, יש פה כמה.

יש שם עוד תוכנה אחת פועלת שצורכת מינימום משאבים (חוץ מהתוכנה והמסד נתונים שכתבתי בפוסט הראשון), ואין לי כל כך אפשרות לעצור שום דבר שם, כי הכל פחות או יותר בייצור, חוץ מאלו הכל זה רק שירותי מערכת וכדו'.
למעשה התוכנות הרציניות זה השלושה שבמעלה הרשימה, וחוץ מזה יש את התוכנה הנוספת בשם the-channel-bin שהיא צורכת פחות מכמה מ"ב.

@dovid כתב בכיצד לתקן דליפת זיכרון בשרת?:

גם על caddy אפשר לוותר אבל זה תלוי בצרכים שלך.

כנ"ל, אני לא יכול לעצור אותו כרגע.

בשביל זה כתבתי שלא רואים את זה בhtop

בעיקרון גם חיפשתי אחרי תהליכים מוסתרים וכו', לא כל כך מסתבר שהוירוס המתוחכם הצליח להסתתר כל כך טוב שהוא לא הופיע בשום רשימה

אני מנהל שרת, שבו מותקנת תוכנה יחידה שצורכת כחצי ג'יגה מהRAM, והמסד נתונים שלה צורך עוד כחצי ג'יגה, והפרוקסי ההפוך (במקרה הזה caddy) עוד בערך חצי גי'גה.
הכל ביחד אמור לקחת בערך 1.5 גי'גה, פלוס עוד קצת לשאר השירתי מערכת וכו', וכך באמת גם רשום ברשימת התהליכים בhtop וכו'.

הבעיה שבסך הכללי של הRAM התפוס מידי פעם (לפעמים תוך כמה שעות) עולה פתאום ל8 ג'יגה RAM, שזה המקסימום של השרת + עוד קצת בקובץ של הזיכרון וירטואלי, ולא חוזר עד להפעלה מחדש של השרת.

מבדיקות שביצעתי הזיכרון הנ"ל לא רשום על שם שום תהליך, אלא ישירות על הקרנל של לינוקס.

זה התחיל לקרות יום אחד, בלי שבוצע עדכון או משהו דומה לפני כן עד כמה שזכור לי (אחרי שזה קרה ביצעתי עדכון לליבה עדכנית ולא עזר).

חיפשתי תהליכים מוסתרים וכדו' ולא נמצא כלום.

מה אפשר לעשות?

האם נותר רק להתקין מחדש את השרת בהתקנה נקייה? והאם זה אמור לעזור?

יש סיכוי כלשהו שזה קשור איכשהו להשמצות על קונטאבו שלפעמים הם לא מספקים את המשאבים בצורה הוגנת?

מסתבר ששכחתי לכתוב כל מיני פרטים נצרכים, אבל זה מה שאני זוכר כרגע.

אגב התוכנה והמסד נתונים פעלו בהתחלה על דוקר, וכרגע העברתי אותם להתקנה ישירה על השרת ורק הcaddy נשאר על דוקר.

@י.פל. כתב במחפש VPS טוב מבחינת מחיר. כמה אתם משלמים?:

לא יודע למה לא מוכר, ולמה @ע-ה-דכו-ע לא כתב את זה:
אורקל נותנים:
4 vCPU
24 GB RAM
במשהו שיוצא כמו 20-25 ש"ח לחודש.
אבל קשה מאוד להרשם שם

עריכה: השימוש שציינתי אמור להיות בחינם. ברמת התשלום, זה התשלום....

זה לא מוכר כיוון שמאוד קשה להירשם שם כמו שציינת, וגם אחרי שנרשמים הרבה פעמים אין שרתים זמינים להגדרה, ומכיוון שבתוכנית החינמית הם יכולים למחוק פתאום את השרת כמו שכתב @אביי .

ובנוסף שזה לא אבונטו אלא מכונה מסוג אורקל, שמשתמשת במנהל חבילות אחר, והכל שונה בה, וגם חומרה של amd64 וכו'.

@אביי כתב במחפש VPS טוב מבחינת מחיר. כמה אתם משלמים?:

@י.פל. שים לב שזה משאבים משותפים ולא ייעודיים,

כל VPS הוא לא ייעודי

@shraga כתב במחפש VPS טוב מבחינת מחיר. כמה אתם משלמים?:

אז אשמח לשמוע ממי שיש לו שרת עם מפרט דומה במקום אחר כמה אתם משלמים עליו.

אני משתמש בקונטאבו,
4 vCPU
8 GB RAM
75 GB NVMe (יש אפשרות באותו מחיר גם ל150 GB SSD)
200 Mbps

ב $3.96 לחודש.

אני יודע שמקובל בעולם שקונטאבו לא מספקים באמת את החומרה כמו שצריך, אבל לא ראיתי עם זה עד היום שום בעיה בביצועים.

היום יש אצלם אפילו חומת אש (משהו חדש מהימים האחרונים)

@אף-אחד-3 כתב בבדיקות חדירות ואבטחה לאוצריא:

@ע-ה-דכו-ע ליתר דיוק היה אפשר להיכנס לכל חשבון שאני יודע את כתובת המייל שלו ויכול להגיש בקשה לאיפוס סיסמה בשמו

נכון, ואת כתובת המייל יכלת לקבל בקלות מהמון מקומות, בין השאר גם באתר.

אגב אפשר עם ההזרקה הזו של השאילתה לקבל עוד הרבה פרטים, וגם לשנות אולי, אני טועה?

@צבי-ש האתר אכן נכתב ע"י אחד שמשתמש המון בAI, ורק עובר על זה קצת (לא תמיד)... זה היה אני במקרה (בעיקר הבסיס, כל ההמשך כבר היה @פלמנמוני בעיקר).

הכוונה שזה לא סתם מקבץ אנשים שכל אחד מנסה את כוחו עד שהוא מחליט שזה לא בשבילו, אלא שני אנשים פחות או יותר, שעושים את זה, והעמידו אתר נחמד מאוד בסופו של דבר.

@צבי-ש כתב בבדיקות חדירות ואבטחה לאוצריא:

לגופו של עניין אם לקחו שליטה כמו שאתה כותב על חשבון מנהל, ואם אני מצרף את מה שאף-אחד-3 כתב, שהוא פשוט ניסה את id מספר 1 אז לכאורה אפשר להיכנס לכל החשבונות גם, ולא רק על חשבון ספציפי

זה לא שהוא ניסה את ID מספר אחד, אלא את הID שהגיע הראשון ברשימת המשתמשים (כנראה היה ממוין לפי נקודות או משהו).
זה נכון שהוא היה יכול לבחור כל אחד מהמשתמשים, אבל מה זה מוסיף יותר מאשר חשבון מנהל?

אגב הוא השתמש בהזרקת שאילתת NoSql במקום טוקן לאיפוס סיסמה, והיה חסר בדיקת טיפוס שיהיה דווקא סטרינג (אם זה מענין).

@מד כתב בבדיקות חדירות ואבטחה לאוצריא:

כלומר זה המקצוע היחיד שהולך לישאר לבני בשר ודם (וג"כ לא להרבה זמן..)

AI יודע בהחלט לבצע גם את זה (כמובן לא כמו בן אדם, כמו כל הדברים), רק שהוא לא תמיד עושה זאת בברירת מחדל.

@אף-אחד-3 @חגי
ברור שמתכנת גם אמור לשים לב, ואפילו מי שמתכנת עם AI, והא ראיה שבכל שאר הנתיבים לא היתה בעיה כזו, ס"ה אמרתי שיכול לקרות כזו פשלה (בתור פשלה שהיא בהחלט אשמה אישית שלו) גם למתכנת, כך היא דעתי.

לאפוקי מאתרים שנבנים בbase44 למשל שמשום מה רואים באמת איך הרבה פעמים אין בהם טיפת אבטחה.

זה לא היה כזה קל, וזו לא היתה פירצה שנבעה מחוסר אבטחה טוטאלי, ס"ה באחד מתוך כל הנתיבים שמאפשרים העלאת קבצים היה חסר שני שורות קוד (בכל הנתיבים זה כן היה חסום).

גם הפירצה הקודמת שמצאת קשה לקרוא לה חוסר אבטחה טוטאלי, כמו נניח אם הנתיבי API היו פתוחים לכל דורש.

כלומר גם מתכנת מקצועי היה עלול לפספס את שני החורים האלו, בשביל זה יש מקצוע מיוחד שנקרא חוקר אבטחה.

@צדיק-תמים כתב בעזרה בשליחת מיילים דרך AWS SES:

@יהודי-טוב זה תלוי בחשבון ובהסטוריית תשלומים שלו

זה לא מגבלות שקשורות להיסטוריית תשלומים, זה מגבלות למניעת ספאם.

@יהודי-טוב כתב בעזרה בשליחת מיילים דרך AWS SES:

למה מיועדים המיילים וכו',

למה באמת הם היו מיועדים?